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.
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.
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.
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.
We use an embedded device to send packets from a serial port over a serial-to-Ethernet converter to a server. One manufacturer we use, Moxa, will always send the packets in the same manner which they are constructed. Meaning, if we construct a packet size of 255, it will always send the packet in a 255 length. The other manufacturer, Tibbo, if we send the packet size 255, it will break the packet up if it is greater than 128. This is the answer I received from the Tibbo engineers at the time:
"From what I understand and what the
engineers said, even if the other
devices provide you with the right
packet size now does not guarantee
that when implemented in other
networks the same will happen. This
is the reason why we feel that packet
size based data transfer through TCP
is not reliable as it was not the way
TCP was designed to be used."
I understand that this may not be how TCP was designed to be used, but if I create a packet of 255 bytes and TCP allows it, then how is this outside of how TCP works? I understand that at some point the packet may get broken up but if the server is expecting a certain packet size and Moxa's offering does not have the same problem as the Tibbo device.
So, is it possible to guarantee a reasonable TCP packet size?
No. TCP is not a packet protocol, it is a stream protocol. It guarantees that the bytes you send will all arrive, and in the right order, but nothing else. In particular, TCP does not give you any kind of message or packet boundaries. If you want such things, they need to be implemented at a higher level by your protocol.