lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] bug #2240 - UDP pcb connect behaviour


From: Ed Sutter
Subject: Re: [lwip-users] bug #2240 - UDP pcb connect behaviour
Date: Mon, 20 Jan 2003 09:14:06 -0500

Leon (& all),
Well, now I'm even more confused.  Here is an example of a
simple UDP-based, connectionless server that does not work
properly on lwIP...

void 
taskMonSrvr(void *notused)
{
  int msglen, sfd;
  unsigned char rcvmsg[128];
  struct sockaddr_in srvr_addr, from_addr;

  sfd = lwip_socket(AF_INET,SOCK_DGRAM,0);
  bzero((char *)&srvr_addr,sizeof(struct sockaddr));
  srvr_addr.sin_family = AF_INET;
  srvr_addr.sin_port = htons(777);
  srvr_addr.sin_addr.s_addr = htonl(INADDR_ANY);

  lwip_bind(sfd,(struct sockaddr *)&srvr_addr,sizeof(struct sockaddr));

  while(1) {
    msglen = sizeof(from_addr);
    lwip_recvfrom(sfd,rcvmsg,sizeof(rcvmsg),0,(struct sockaddr 
*)&from_addr,&msglen);
    lwip_sendto(sfd,"hello!\n",7,0,(struct sockaddr 
*)&from_addr,sizeof(from_addr));
  }
}
Do you agree that this server should respond to any client?

AFAIK, this server should simply respond with "hello!\n" to any client that
tries to talk to it.  In my system it only communicates with the first client
that attempts to talk to it.  Is there something wrong with this approach?
I've used this with many other stacks and it works fine.

I agree that a UDP-based "connection" can be set up to only communicate
with one other peer, but that should not the case with this server.
The above code should respond to any peer, not just the first one.
Agree?

Ed
Leon Woestenberg wrote:
> 
> Hello,
> 
> > Yes, I beleive that's correct.  My change to udp.c for this
> > assumes connectionless behaviour, so now I'm going to
> > advertise my stupidity... Isn't that the way UDP should work?
> >
> 
> UDP is connectionless in the sense that it merely tries to send
> datagrams to a certain address without any attempts to keep
> a communication channel open with that address.
> 
> An UDP protocol control block (think of a simple socket) can
> send and receive datagrams to/from any host during operation,
> unlike a TCP connection.
> 
> A UDP PCB can however, assume a connected state, where
> the remote address is used to send datagrams to, and to accept
> only datagrams from that address.
> 
> This kind of UDP PCB is referred to as a "connected" PCB (or
> socket) which might introduce the confusion, as the UDP
> communication protocol is still "connection-less".
> 
> > Assuming there are cases where accept() and connect() are
> > used with UDP, then maybe a real fix would be to have some
> > kind of flag field in the pcb that allows udp_input() to
> > determine if it is a connection or connectionless bind.
> >
> There is no such thing, and AFAIK nothing needs to be fixed.
> (unless netcon_*() has a bug).
> 
> Regards,
> 
> Leon.
> 
> >
> >
> > Leon Woestenberg wrote:
> > >
> > > Ed Suller submitted this bug report. (Thanks Ed.)
> > >
> > > >A UDP server appears to "lock on" to the IP address of
> > > >he first client that communicates with it. After the first
> > > >client transaction, no other client (different IP) can
> > > >communcate with that server. Assuming that it is agreed
> > > >by all that this is a bug, I have what I think is a
> > > >fix for this and will submit a patch.
> > >
> > > This behaviour corresponds with accept() or connect(), where the socket
> > > connects with the
> > > remote IP address and remote UDP port address. Ed's fix probably
> implements
> > > recvfrom() behaviour,
> > > where the socket stays unconnected to a remote address.
> > >
> > > None of both is wrong, but we should make both available and especially
> well
> > > documented.
> > >
> > > Regards, Leon.
> > >
> > > _______________________________________________
> > > lwip-users mailing list
> > > address@hidden
> > > http://mail.nongnu.org/mailman/listinfo/lwip-users
> 
> ----------------------------------------------------------------------------
> ----
> 
> > _______________________________________________
> > lwip-users mailing list
> > address@hidden
> > http://mail.nongnu.org/mailman/listinfo/lwip-users
> >


Leon Woestenberg wrote:
> 
> Hello,
> 
> > Yes, I beleive that's correct.  My change to udp.c for this
> > assumes connectionless behaviour, so now I'm going to
> > advertise my stupidity... Isn't that the way UDP should work?
> >
> 
> UDP is connectionless in the sense that it merely tries to send
> datagrams to a certain address without any attempts to keep
> a communication channel open with that address.
> 
> An UDP protocol control block (think of a simple socket) can
> send and receive datagrams to/from any host during operation,
> unlike a TCP connection.
> 
> A UDP PCB can however, assume a connected state, where
> the remote address is used to send datagrams to, and to accept
> only datagrams from that address.
> 
> This kind of UDP PCB is referred to as a "connected" PCB (or
> socket) which might introduce the confusion, as the UDP
> communication protocol is still "connection-less".
> 
> > Assuming there are cases where accept() and connect() are
> > used with UDP, then maybe a real fix would be to have some
> > kind of flag field in the pcb that allows udp_input() to
> > determine if it is a connection or connectionless bind.
> >
> There is no such thing, and AFAIK nothing needs to be fixed.
> (unless netcon_*() has a bug).
> 
> Regards,
> 
> Leon.
> 
> >
> >
> > Leon Woestenberg wrote:
> > >
> > > Ed Suller submitted this bug report. (Thanks Ed.)
> > >
> > > >A UDP server appears to "lock on" to the IP address of
> > > >he first client that communicates with it. After the first
> > > >client transaction, no other client (different IP) can
> > > >communcate with that server. Assuming that it is agreed
> > > >by all that this is a bug, I have what I think is a
> > > >fix for this and will submit a patch.
> > >
> > > This behaviour corresponds with accept() or connect(), where the socket
> > > connects with the
> > > remote IP address and remote UDP port address. Ed's fix probably
> implements
> > > recvfrom() behaviour,
> > > where the socket stays unconnected to a remote address.
> > >
> > > None of both is wrong, but we should make both available and especially
> well
> > > documented.
> > >
> > > Regards, Leon.
> > >
> > > _______________________________________________
> > > lwip-users mailing list
> > > address@hidden
> > > http://mail.nongnu.org/mailman/listinfo/lwip-users
> 
> ----------------------------------------------------------------------------
> ----
> 
> > _______________________________________________
> > lwip-users mailing list
> > address@hidden
> > http://mail.nongnu.org/mailman/listinfo/lwip-users
> >

Attachment: els.vcf
Description: Card for Ed Sutter


reply via email to

[Prev in Thread] Current Thread [Next in Thread]