"Mark Phillips" <[email protected]> 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.
_______________________________________________
lwip-users mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/lwip-users
