What would happen if my udp package is larger than mtu? Say my package is 512 bytes, after encapsulated, the package is 572 bytes. In transporting, some intermediate node fix it mtu size to 512 bytes, so what happens? Does my package simply being discarded?
In general, what is the best size of a udp package which fits for most of network situation?
The package will still be sent, however the network interface layer (i.e. ethernet) will use multiple network transmissions to send it. You are still limited in size however by the maximum size for a UDP datagram (65535) as enforced by UDP/IP. See MTU and UDP Packets on Wikipedia for more info.
Related
I want to use UDP to do Interprocesses communication, I know the maximum size for a UDP datagram is ~64K. but whether is that true for loopback?
TL;DR: 64k, if you don't care about IP fragmentation. MTU if you do.
Even though UDP max packet size is 64k, the actual transfer size is governed by the interface's MTU.
Any packet larger than the MTU (including IP and UDP overhead) will be fragmented to multiple layer-2 packets.
So, while you can always send a 64k UDP packet, you may end up with more than one IP packet, which add latency and increase the chance of packet drop (if one fragment is lost - all the datagram is lost).
The good news is that you don't have to worry about fragmentation yourself - the kernel will take care of fragmentation and reassembly so your application will see a single datagram of 64k in size.
Since you're asking about the loopback interface, packet drop is not an issue, so you're only bound by UDP's size field.
If you would like to avoid IP fragmentation, you need to query the interface's MTU and make sure your datagrams are smaller (again, including IP and UDP overhead).
On my Mac the loopback interface default MTU is 16384:
$ ifconfig lo0
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
...
On Linux, you can get/set an interface MTU programmatically with SIOCGIFMTU/SIOCSIFMTU ioctl (man 7 netdevice).
I write P2P system based on Kadelmia approach. My question is related to type of transport to use: UDP or TCP.
The Kadelmia documentation defines UDP, but my concern is payload size. As far as I know, UDP grantees delivery of 548 bytes. But there are messages, which are defined by documentation, with length greater then 548 bytes (for example response on FIND_NODE). The question: should I use TCP instead of UDP?
with length greater then 548 bytes
That's the RFC-defined MTU for ipv4, but in practice almost all nodes support more, at least 1400 and some cases can be covered by fragmentation too. For IPv6 the guaranteed MTU is higher.
The question: should I use TCP instead of UDP?
You should use UDP, see this Q&A for reasons. If you need to transfer larger data at the end of a lookup you can still use TCP as next layer protocol, but that is beyond the scope of kademlia's routing algorithm.
for example response on FIND_NODE
Assuming 256bit node IDs (32 bytes) and 18byte contacts (IPv6) you can fit 10 ID, address pairs into 548 bytes with a few bytes to spare for headers. It's crammed but doable.
Would sending lots a small packets by UDP take more resources (cpu, compression by zlib, etc...). I read here that sending one big packet of ~65kBYTEs by UDP would probably fail so I'm thought that sending lots of smaller packets would succeed more often, but then comes the computational overhead of using more processing power (or at least thats what I'm assuming). The question is basically this; what is the best scenario for sending the maximum successful packets and keeping computation down to a minimum? Is there a specific size that works most of the time? I'm using Erlang for a server and Enet for the client (written in c++). Using Zlib compression also and I send the same packets to every client (broadcasting is the term I guess).
The maximum size of UDP payload that, most of the time, will not cause ip fragmentation is
MTU size of the host handling the PDU (most of the case it will be 1500) -
size of the IP header (20 bytes) -
size of UDP header (8 bytes)
1500 MTU - 20 IP hdr - 8 UDP hdr = 1472 bytes
#EJP talked about 534 bytes but I would fix it to 508. This is the number of bytes that FOR SURE will not cause fragmentation, because the minimum MTU size that an host can set is 576 and IP header max size can be 60 bytes (508 = 576 MTU - 60 IP - 8 UDP)
By the way i'd try to go with 1472 bytes because 1500 is a standard-enough value.
Use 1492 instead of 1500 for calculation if you're passing through a PPPoE connection.
Would sending lots a small packets by UDP take more resources ?
Yes, it would, definitely! I just did an experiment with a streaming app. The app sends 2000 frames of data each second, precisely timed. The data payload for each frame is 24 bytes. I used UDP with sendto() to send this data to a listener app on another node.
What I found was interesting. This level of activity took my sending CPU to its knees! I went from having about 64% free CPU time, to having about 5%! That was disastrous for my application, so I had to fix that. I decided to experiment with variations.
First, I simply commented out the sendto() call, to see what the packet assembly overhead looked like. About a 1% hit on CPU time. Not bad. OK... must be the sendto() call!
Then, I did a quick fakeout test... I called the sendto() API only once in every 10 iterations, but I padded the data record to 10 times its previous length, to simulate the effect of assembling a collection of smaller records into a larger one, sent less often. The results were quite satisfactory: 7% CPU hit, as compared to 59% previously. It would seem that, at least on my *NIX-like system, the operation of sending a packet is costly just in the overhead of making the call.
Just in case anyone doubts whether the test was working properly, I verified all the results with Wireshark observation of the actual UDP transmissions to confirm all was working as it should.
Conclusion: it uses MUCH less CPU time to send larger packets less often, then the same amount of data in the form of smaller packets sent more frequently. Admittedly, I do not know what happens if UDP starts fragging your overly-large UDP datagram... I mean, I don't know how much CPU overhead this adds. I will try to find out (I'd like to know myself) and update this answer.
534 bytes. That is required to be transmitted without fragmentation. It can still be lost altogether of course. The overheads due to retransmission of lost packets and the network overheads themselves are several orders of magnitude more significant than any CPU cost.
You're probably using the wrong protocol. UDP is almost always a poor choice for data you care about transmitting. You wind up layering sequencing, retry, and integrity logic atop it, and then you have TCP.
i am writing my programming for ar drone using UDP, but the drone sometimes hangs, i think maybe the UDP is not big enough, is there any way to improve the situation if still using UDP?
UDP datagram sizes are limited by:
The outgoing socket send buffer. Defaults for this vary wildly, from 8k in Windows to 53k or more in other systems.
The Path MTU or Maximum Transmission Unit of the entire network path between you and the receiver. This is typically no more than 1260 bytes.
The safest size for a UDP datagram is 534 bytes as this will never be fragmented by the transport. If you're planning on sending datagrams larger than this you need to consider a different transport, usually TCP.
I am using the GCDAsyncUdpSocket to send/receive data to a multicast group. In the GCDAsyncUdpSocket.m file, I found the setting bellow and changed the value to 32768 for example. But I can't still receive any packet that is larger than 9216 bytes.
max4ReceiveSize = 9216;
max6ReceiveSize = 9216;
Is there another setting?
Edit:
I discovered that the GCDAsyncUdpSocket class did provide a method to set this value called setMaxReceiveIPv4BufferSize. Tried that but it still only received at around 9216 bytes.
It would help to know exactly which operating system you are on, as the settings vary. On OS X 10.6, look at:
# sysctl net.inet.udp.maxdgram
net.inet.udp.maxdgram: 9216
However, you must keep in mind that the maximum transmit unit (MTU) of any data path will be determined by the smallest value supported by any device in the path. In other words, if just one device or software rule refuses to handle datagrams larger than a particular size, then that will be the limit for that path. Thus there could be many settings on many devices which affect this. Also note that the MTU rules for IPv4 and IPv6 are radically different, and some routers have different rules for multicast versus unicast.
In general, it is not safe to assume that any IP datagram larger than a total of 576 bytes (including all protocol headers) will be allowed through, as 576 the maximum IP packet size which IPv4 guarantees will be supported. For IPv6, the guaranteed size is 1280. Most devices will support larger packets, but they are not required to.