Prev: Platform independant scripts?
Next: Ryhm�n sfnet.urheilu virallinen kuvaus
From: David Schwartz on 14 Jun 2008 17:31
On Jun 13, 2:47 am, Rainer Weikusat <rweiku...(a)mssgmbh.com> wrote:
> David Schwartz <dav...(a)webmaster.com> writes:
> > On Jun 11, 4:15 am, Rainer Weikusat <rweiku...(a)mssgmbh.com> wrote:
> >> The only 'relevant standards' here would be RFC768 ('user datagram
> >> protocol') and RFC791 ('internet protocol'). Neither of both prohibits
> >> cannibalism. Hence, anyone coming too close to a UDP implementation
> >> runs the very real danger of being eaten by it.
>
> > Actually, no, since the semantics of things like 'select' and
> > 'recvmsg' are specified by POSIX.
>
> You were refering to an 'UDP standard', and that's what I was writing
> about.

But I never claimed that was the only relevant standard. That was your
claim, and it's false. I included the UDP standard with several other
standards and made a claim about all of them together.

> [...]
>
> > If you mean dropping a datagram, this should
> > never be any kind of big deal. One of IP's main points is that
> > implementations are free to drop datagrams,

> That's one of your ideas about IP-implementations.

If you're going to resort to "that's what you think", don't bother
replying. If you have some kind of actual response to that, go for it.

DS
From: Rainer Weikusat on 15 Jun 2008 09:19
David Schwartz <davids(a)webmaster.com> writes:
> On Jun 13, 2:47�am, Rainer Weikusat <rweiku...(a)mssgmbh.com> wrote:
>> David Schwartz <dav...(a)webmaster.com> writes:
>> > On Jun 11, 4:15�am, Rainer Weikusat <rweiku...(a)mssgmbh.com> wrote:
>> >> The only 'relevant standards' here would be RFC768 ('user datagram
>> >> protocol') and RFC791 ('internet protocol'). Neither of both prohibits
>> >> cannibalism. Hence, anyone coming too close to a UDP implementation
>> >> runs the very real danger of being eaten by it.
>>
>> > Actually, no, since the semantics of things like 'select' and
>> > 'recvmsg' are specified by POSIX.
>>
>> You were refering to an 'UDP standard', and that's what I was writing
>> about.
>
> But I never claimed that was the only relevant standard. That was your
> claim, and it's false.

| You were refering to an 'UDP standard', and that's what I was writing
| about.

In particular, the 'only relevant standards' was meant to only refer
to UDP.

[...]

>> > If you mean dropping a datagram, this should
>> > never be any kind of big deal. One of IP's main points is that
>> > implementations are free to drop datagrams,
>
>> That's one of your ideas about IP-implementations.
>
> If you're going to resort to "that's what you think", don't bother
> replying. If you have some kind of actual response to that, go for
> it.

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.

From: David Schwartz on 15 Jun 2008 13:18
On Jun 15, 6:19 am, Rainer Weikusat <rweiku...(a)mssgmbh.com> 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
From: Rainer Weikusat on 15 Jun 2008 13:47
David Schwartz <davids(a)webmaster.com> writes:
> On Jun 15, 6:19�am, Rainer Weikusat <rweiku...(a)mssgmbh.com> 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.

The 'random' would be a picturesque detail which is not really
relevant for the point of my text.

> 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.

And that's precisely why I described this as 'randomly dropping a
datagram': The implementation may or may not do so, depending on
circumstances outside the control of an application, which this
application cannot even observe, ie the behaviour is unpredictable.

[...]

> It's precisely the same thing with UDP. The standards permit a UDP
> datagram to be dropped at any time.

That you keep repeating this particular falsehood doesn't make it less
false. Neither of both RFCs contains anything about 'reasons why
[received] datagrams could be dropped' or 'permissions regarding
dropping of received datagrams'. They (RFC791, actually) just state
that the protocol does not attempt to deal with possible loss
datagrams on their way from the sender to the receiver (even this is
already more than is actually said in the text).
From: David Schwartz on 16 Jun 2008 15:14
On Jun 15, 10:47 am, Rainer Weikusat <rweiku...(a)mssgmbh.com> wrote:

> > It's precisely the same thing with UDP. The standards permit a UDP
> > datagram to be dropped at any time.

> That you keep repeating this particular falsehood doesn't make it less
> false. Neither of both RFCs contains anything about 'reasons why
> [received] datagrams could be dropped' or 'permissions regarding
> dropping of received datagrams'. They (RFC791, actually) just state
> that the protocol does not attempt to deal with possible loss
> datagrams on their way from the sender to the receiver (even this is
> already more than is actually said in the text).

"The internet protocol does not provide a reliable communication
facility. There are no acknowledgments either end-to-end or
hop-by-hop. There is no error control for data, only a header
checksum. There are no retransmissions. There is no flow control."

I'm not sure what you understand "there is no flow control" to mean,
but I understand it to mean that dropping a datagram is acceptable at
any time. Essentially, dropping datagrams whenever you can't keep them
all is the alternative to flow control.

Note that it doesn't see these are the only ways in which UDP is
unreliable. It states that UDP is not a reliable communication
facility. Then it lists several ways in which it is unreliable.

It is quite clear from the entire design and intention of UDP that the
solution to any delivery problem is to discard the datagram.

DS
 |  Next  |  Last
Pages: 1 2 3
Prev: Platform independant scripts?
Next: Ryhm�n sfnet.urheilu virallinen kuvaus