Re: [lwip-users] RE: How to send a large (over 1500 bytes) data onetime ?

[David Empson]

"Mark Phillips" <address@hidden> wrote:
> Each UDP packet is a complete message, and is sent without
> fragmentation, reassembly, confirmation, or re-transmission.
>
> Therefore, a UDP packet must be smaller (or the same size) as the
> smallest MTU on the path it's transferred on.
>
> This isn't a property of lwIP, it's a fundamental property of UDP.

Since when? UDP has a maximum segment length of nearly 64K, and IP supports 
fragmentation and reassembly on most hosts, allowing UDP to be used to send 
data which exceeds both the smallest MTU for the path and that of the local 
network.

Limiting the length of UDP packets to the smallest MTU on the network path 
is a good principle for maximising the chance of UDP data arriving, and is 
required if the receiving host hasn't implemented IP reassembly (e.g. memory 
constrained embedded devices), but it is not required in general.

In the case of LWIP, as far as I can see all the code is there to allow 
sending and receiving maximum length UDP packets (at least in LWIP 1.1.0 and 
later - I haven't used earlier versions). The influencing factors are:

1. For the sender to be able to fragment IP datagrams (i.e. exceed the local 
network MTU), the IP_FRAG option must be enabled. It is on by default in 
opt.h, so this would only be a problem if disabled in lwipopts.h.

2. For the receiver to be able to reassemble fragmented IP datagrams, the 
IP_REASSEMBLY option must be enabled. It is on by default in opt.h, so this 
would only be a problem if disabled in lwipopts.h.

3. There are additional configuration parameters for specifying the maximum 
size of a reassembled datagram. Recent versions of LWIP use pbufs, and 
IP_REASS_MAX_PBUFS controls how many of them will be held for reassembly. 
Older versions (e.g. 1.1.0) used a static buffer.

4. The maximum amount of data which can be sent via UDP with the socket 
layer API will be influenced by the number of available pbufs and the size 
of them. Make sure you aren't hitting memory allocation limits. The receiver 
may have a similar issue.