UDP packet not sent

[gregory.menke at gsfc.nasa.gov]

Rolf Schroedter writes:
 > I know, that UDP itself is not reliable, it's not guarantied
 > that the sent packet will be received at the other side.
 > But I expect that at least the UDP packet is *send out*,
 > when sendto(..,MSG_WAITALL,..) returns success.
 > 
 > Running RTEMS 4.6b with the open_eth driver at the LEON-SPARC.
 > The application receives requests and acknowledges them by
 > sending data.
 > E.g. it sends
 > 	60 packets x 1040 bytes
 > 	1 packet x N bytes
 > 	1 packet x 100 bytes
 > 
 > All calls result=sendto(buf, size,MSG_WAITALL,..) return result=size.
 > However snooping with ethereal shows that
 > 	if (N >= 966) then all packets are sent
 > 	if (N <= 964) then this packet is *not sent*
 > 
 > The result is stable. In all cases the following last 100 byte
 > packet is sent.
 > 
 > Any ideas why and where the packet is swallowed ?
 > Thanks,
 > Rolf.
 > 


UDP is free to drop your packet at any time, including the sending and
receiving stack.  The sendto() return != -1 indicates only that the
stack accepted your packet.  This is true for all stacks.  That said,
different IP stacks will drop packets at different times under
different circumstances.

If you're working on a switched network, you generally won't see very
many (if any) packets dropped by the network itself- but regardless of
the network type, both ends are subject to buffering issues.

As always, you must assume any UDP packet may be dropped at any time-
you cannot depend on any behavior other than a "best effort" attempt
by the stack to transmit your packet which begins when you invoke
sendto().

If you need reliability, you have to use a different protocol or have
your application software impose an ack/retry regime.  There are a
wide variety of implementations of both types of approach.  Joel
helped us port "MDP" to RTEMS for one project, it has all sorts of
features for reliable file delivery as well as messaging all over UDP.
Its one example at least...

Gregm