Re: Question on select() and sockets

On Jun 15, 6:19 am, Rainer Weikusat <rweiku...@xxxxxxxxxxx> wrote:

I already posted all the 'actual responses', including quoting a part
of the IP-RFC. Actually, my sentence above is such an 'actual
response', too: The behaviour you were writing about is not specified
by these RFCs, which describe the respective protocols and the
services offered (or not offered) by them. Starting from the protocol
behaviour, you came to the conclusion that 'a UDP-implementation may
elect to be as useless as technically possible, eg by randomly
dropping data it has already received'. But the only applicable thing
which is actually defined in the standard regarding this is that the
UDP- and IP-protocol modules provide no help to an applications which
would need to deal with an implementation behaving in this way.

Wow, so much nonsense in such a small space!

First, you mischaracterize the behavior as "randomly dropping data".
Nobody ever mentioned such a thing. An implementation may fail a
'malloc' request because it's low on memory, and as far as an
application can tell, this can happen at any time. In principle, an
implementation could always return NULL to 'malloc', making it not
particularly useful. You can describe any implementation that ever
returns NULL for 'malloc' for reasons the application cannot readily
determine as "randomly failing".

The fact that the standards permit an implementation to randomly
return NULL on 40% of the 'malloc' calls doesn't mean an
implementation should do that. But it does mean that an application
has to be prepared for *any* 'malloc' call to fail.

It's precisely the same thing with UDP. The standards permit a UDP
datagram to be dropped at any time. All they ask for is best effort.
As such, an application has to be prepared for a datagram to be
dropped at any time. If it considers such behavior disfunctional and
doesn't handle it gracefully, it's as broken as an application that
can't handle a NULL return from 'malloc'.

DS
.