UDP over v6: payload truncated at 1024 bytes
Wed Apr 7 17:03:09 CEST 2004
Matthias Lang <matthias@REDACTED> wrote:
>I know that Fredrik's immediate problem [erlang's UDP receive buffer
>size was too small for his application] has been solved, but the claim
>that UDP packets aren't re-assembled by the OS has been bugging me for
>a few days:
You get bugged too easily.:-)
> Peter Lund> At least in IPv4 (and TCP) you cannot ever count on any packet
> Peter Lund> of any size to arrive at the destination without being fragmented
> Peter Lund> into 2 or more parts.
>This is true at L1, but it is not relevant to Fredrik's problem.
> Fredrik> But surely the operating system should re-assemble the
> Fredrik> two fragments before passing it to the application, even
> Fredrik> for UDP, no?
> Peter Lund> No! The OS (any OS) does not help you when running TCP/IPv4.
>No!!!! Fredrik is correct.
>Linux DOES re-assemble fragmented IP datagrams for TCP/IPv4.
Yes, of course.
>I suspect that re-assembling IP datagrams is required by POSIX,
>i.e. the behaviour will be the same for Solaris, BSD and modern
>variants of Windows. But I haven't checked that. Nor do I have my copy
>of Stevens handy.
Absolutely true - in fact there's no possible way for an application to
handle IP fragmentation itself via the standard socket API - the
information needed just isn't available (fragments can of course arrive
out of order, or be lost).
What Peter was talking about was something entirely different - the
issue of implementing a datagram service on top of TCP (like, say,
Erlang distribution does). Since TCP will not preserve the boundaries of
these "user-level datagrams" for you, you have to do it yourself -
otherwise you'll run the risk of not just getting datagram "fragments",
but of multiple datagrams being concatenated, or any combination of the
two (e.g. last part of one datagram and first part of the next one).
This issue doesn't exist with UDP, since it's a "true" datagram service
- it does preserve the boundaries for you. Instead there are many other
issues, one of which Fredrik ran into.
More information about the erlang-questions