UDP: first packets not sent

[gregory.menke at gsfc.nasa.gov]

Rolf Schroedter writes:
 > I'm using UDP to a fixed server with the open_eth RTEMS driver.
 > 	fd = socket(...);	/* Open the socket */
 > 	connect(fd, ...);	/* specify destination address */
 > If sending data every 10 milliseconds is started immediately
 > 	for(;;) {
 > 		send(fd,...);
 > 		sleep_10_milliseconds();
 > 	}
 > then the first ~16-17 packets are completely lost.
 > ETHEREAL shows that they are not sent by the RTEMS host.
 > Seems to me that RTEMS ignores all send() calls until the
 > hardware (ethernet) address of the destination is detected (ARP).
 > Send() doesn't return any error.
 > 
 > If sending data is started ~3 seconds after calling connect(),
 > then everything is fine.
 > 
 > Is this an RTEMS problem, or am I missing something ?
 > Is there a way to know, when data can be sent ?
 > 

No ip stack can send anything but a broadcast over ethernet until the
destination address is known, and the only way thats done is to
perform an arp exchange.  There are various ways to handle the arp
table, ranging from tweaking timeouts to making entries persistent.
Different stacks might queue outgoing packets until the destination
ethernet address is known, but they don't have to.

If you need to keep an arp entry in the table over time periods where
it would normally expire, the easiest thing to do is ping the
destination or otherwise communicate with it a couple times a minute.

Or, you could presumably enumerate your local arp table to see if the
destination's entry is there, but I think doing so suggests you're not
approaching the problem well since you've become tied to a particular
physical layer, and avoiding that is what IP is good at.

The UDP send functions make no guarantee that the packet will actually
be transmitted, only that they will try to and silently discard it
otherwise.  Your UDP packets are subject to loss or duplication at any
point in the sending & receiving stacks as well as on the wire.  Thats
not to say its going to be lost or duplicated or even that its likely,
but that you have to design your algorithms to handle the possibility.
Also, connect() over UDP is still just plain old UDP.

The only way to know if a destination is going to receive something is
if you try to send it and get back some kind of response.  And even
then, you don't know if its still available after it sent its ack
response.  You simply cannot assume relability and treat network
communications like you might treat reading/writing a file.

Gregm