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).
Related
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.
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.
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.