Re: want opinions on possible glitch in 2.4 network error reporting

[Ben Greear <greearb@candelatech.com>]

However, if you use non-blocking IO you will get EAGAIN if
there is no buffer space.  Blocking calls should always
block untill there is buffer space.

Also, just because select says the socket/poll is writable, it
may not be (immediately) because you can send UDP packets
that are larger than 2048 bytes, and that is the cutoff that
tells select the socket is writable...

I've actually sent a patch to Dave Miller to make select/poll
wait untill there is 64k of buffer space (the maximum size of
a UDP packet), but he is still reviewing the issue.


Enjoy,
Ben

Richard B. Johnson wrote:

> On Wed, 6 Feb 2002, Chris Friesen wrote:
> 
> [SNIPPED...]
> 
> 
> 
>>I ran into a somewhat related issue on a 2.2.16 system, where I had an app that
>>was calling sendto() on 217000 packets/sec, even though the wire could only
>>handle about 127000 packets/sec.  I got no errors at all in sendto, even though
>>over a third of the packets were not actually being sent.
>>
>>
> 
> In principle, sendto() will always succeed unless you provided the
> wrong parameters in the function call, or the machines crashes, at
> which time your task won't be there to receive the error code anyway.
> 
> Hackers code sendto as:
> 	sendto(s,...);
> Professional programmers use:
> 	(void)sendto(s,...);
> 
> checking the return value is useless.
> 
> Note that the man-page specifically states that ENOBUFS can't happen.
> 
> You cannot assume that any sendto() data actually gets on the wire, much
> less to its destination. With any user-datagram-protocol, both ends,
> sender and receiver, have to work out what they will do with missing
> packets and packets received out-of-order.
> 
> 
> Cheers,
> Dick Johnson


-- 
Ben Greear <greearb@candelatech.com>       <Ben_Greear AT excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear