This won't work. Standard ethernet frame sizes are (if I
remember correctly) around 1500 bytes.
Unless he's using jumbo frames which allow an MTU of 9000
bytes.
Sending anything larger will cause the packet to fragment. UDP
packets don't know about ordering, so when it is fragmented
into 4 pieces, you could get them in reverse order,
Except it's IP, not UDP that does the fragmenting, and IP does know
about fragment ordering, so you won't get fragments mixed up.
Quoting from RFC791:
The internet protocol also provides for fragmentation and
reassembly of long datagrams, if necessary, for
transmission through "small packet" networks.
[...]
The internet fragmentation and reassembly procedure needs
to be able to break a datagram into an almost arbitrary
number of pieces that can be later reassembled. The
receiver of the fragments uses the identification field to
ensure that fragments of different datagrams are not mixed.
The fragment offset field tells the receiver the position
of a fragment in the original datagram. The fragment
offset and length determine the portion of the original
datagram covered by this fragment. The more-fragments flag
indicates (by being reset) the last fragment. These fields
provide sufficient information to reassemble datagrams.
or get the first and last packets while the middle two never
get there, etc.
Nope. IP handles fragmentation and reassembly of UDP segments
in a transparent manner.
If you MUST have this structure, then use TCP sockets, as they
guarantee the ordering of the data is sequential, and make
best-effort network guarantees that your data will actually
get to its destination.
TCP guarantees the ordering and reliably transfer of bytes
within a stream. UDP doesn't guarantee the order of datagrams,
nor the reliable and non-duplcated delvery of same. But, UDP
will not re-order data within a datagram.
···
On 2006-01-24, Josiah Carlson <jcarlson@uci.edu> wrote:
--
Grant Edwards grante Yow! If I pull this SWITCH
at I'll be RITA HAYWORTH!! Or
visi.com a SCIENTOLOGIST!