UDP max data length ?
Martin Roth
the sendto() function over a UDP socket. Is it ~ 65Kbytes or it is limited
by the size of MTU ?
2. Is there any limitation for the DATA size over UDP socket in case of
broadcasting over UDP? Is it still 65Kbytes or it is limited by the size of
MTU ?
3. Assume that the receiver receives the data by recvfrom() on UDP socket.
Is there a way to assure that the DATA is received in one block on return
from recvfrom() on UDP socket? Does IP fragmentation/defragmentation assure
this ? What about broadcast msgs ?
Thanks,
Martin Roth
Mailto:bmr...@email.mot.com
David Laight
> 1.I would like to know what is the maximum size of data I can send by using
> the sendto() function over a UDP socket. Is it ~ 65Kbytes or it is limited
> by the size of MTU ?
It ought to be ~ 65k, UDP datagrams should be fragmented by IP.
> 2. Is there any limitation for the DATA size over UDP socket in case of
> broadcasting over UDP? Is it still 65Kbytes or it is limited by the size of
> MTU ?
Not sure...
> 3. Assume that the receiver receives the data by recvfrom() on UDP socket.
> Is there a way to assure that the DATA is received in one block on return
> from recvfrom() on UDP socket? Does IP fragmentation/defragmentation assure
> this ? What about broadcast msgs ?
The entire datagram has to be assembled by IP before being passed to
UDP. Thus it will be returned by a single recvfrom() call.
vxworks might be broken and object to datagrams longer that the
socket buffer size, IIRC some systems don't like >32k datagrams.
Receiving fragmented datagrams requires that the target system have
enough buffer space to receive all of the ethernet frames back to
back. As the datagram gets longer this gets less and less likely
for systems that incapable of sustaining the network bamdwidth.
If wireless links are present you will lose out badly.
David
Leonid Rosenboim
"Martin Roth" <bmr...@email.mot.com> wrote in message
news:ariqms$ar4$1...@newshost.mot.com...
> 1.I would like to know what is the maximum size of data I can send by
using
> the sendto() function over a UDP socket. Is it ~ 65Kbytes or it is limited
> by the size of MTU ?
>
socket, up until 64Kbytes.
The default socket buffer is 4k, and you need to change it with
setsockoption()
before being able to send larger packets. For the receiver to be able to
receive
a larger then default UDP packet, receive buffer size should be increased
accordingly.
I recommend to incrase the rx buffer to 2X max packet size to avoid packet
loss
that resul tfrom application latency.
> 2. Is there any limitation for the DATA size over UDP socket in case of
> broadcasting over UDP? Is it still 65Kbytes or it is limited by the size
of
> MTU ?
>
The size of DATA is limitted bu socket sen dbuffer size, DATA+UDP+IP is
limitted
by the inherent IPv4 64x1024 bytes limit.
Regarding BROADCAST or MULTICAST however, it is a bad idea to rely on IP
fragmentation, and thus the Max DATA+UDP+IP+MAC packet should not exceed
1500 bytes (standard MTU.
It is my experience that in a broad/multi case scenario, the IP
fragmentation
increases probability of packet loss beyond reasonable.
In certain Multicast applications where large WANs are concerned, it is
recommended
to limit pacet by PathMTU, which is 576 bytes, unless it can be explicitly
discovered.
[Ref: RTP]
> 3. Assume that the receiver receives the data by recvfrom() on UDP socket.
> Is there a way to assure that the DATA is received in one block on return
> from recvfrom() on UDP socket? Does IP fragmentation/defragmentation
assure
> this ? What about broadcast msgs ?
It is assured that the UDP recvfrom() (or read, or recv) will EITHER receive
the
ENTIRE UDP packet in one peice, or return an ERROR to the receiver, if the
recvfrom() buffer is smaller then the packet stored in socket.
If the socket receve buffer is too small, the packet is discarded with no
diagnostic except the UDP statistics counter.
--
-----------------------------------------------------------------------
Leonid Rosenboim Visit: http://www.masada2000.org/historical.html
Consultant Email: my first name at consultant dot com
Martin Roth
Thanks, for the reply.
Our application broadcasts a heartbeat msg (in XML schema) each 60 seconds
to an server running on Linux . The heartbeat msg length is currently ~1400
bytes. We need to extend the format, so the length becomes ~1600 bytes.
Since we are changing the application protocol, we have two alternatives:
1) To proceed broadcasting 1600 bytes UDP msg on UDP socket as before, thus
exceeding the MTU of 1500 bytes.
2) To compress the msg (XML is highly compressible), thus we will broadcast
~500 bytes of compressed XML data
How reliable is solution #1 ?
Martin
"Leonid Rosenboim" <My_1s...@Consultant.Com> wrote in message
news:newscache$linx5h$gcc$1...@lnews.actcom.co.il...