I know that UDP is inherently unreliable, but when connecting to localhost I would expect the kernel handles the connection differently since everything can be handled internally. So in this special case, is UDP considered a reliable protocol, or will the kernel still potentially junk some packets if buffers are overrun?
I have seen UDP to localhost dropping packets. We think we were overloading the kernel queue. All we know for sure is that it was dropping packets.
I repeat a previous answer to a related question. To remain portable always anticipate your UDP sockets might drop packets or receive out of order data.
I don't think that UDP (or any other network protocol) says anything about different behavior when connecting to localhost. So the answer will depend on the specific kernel that you're using. Best to assume that UDP will behave like UDP.
Related
I can deliver normal UDP messages between two computers using a direct ethernet connection using my software. But I couldn't do the same for multicasting messages, I've tried other softwares that can send and receive multicast UDP messages and they didn't work as well. So I thought and wanted to ask if a direct Ethernet connection is a proper pyhsical setup or not. And if not what should I do?
Yes, a direct ethernet supports multicast. As opposed to an NBMA network like frame relay (rare these days) which does not support multicast for example.
Make sure you are not actually using a switch (which is a bridge) that has IGMP snooping enabled. IGMP snooping will not propagate multicast to nodes that have not sent an IGMP join (assuming your software does not do the join).
How likely are UDP packets on loopback to be delivered out of order? I ask because this affects the reliability of loopback TCP sockets.
I can't guarantee this, but I'd say you won't get out of order delivery of packets on the loopback interface.
The classic example of out-of-order delivery is that different packets sent between 2 hosts on the internet may travel different routes and thus be delivered out-of-order. Obviously that does not happen on the loopback interface, so unless someone on purpose programmed out-of-order behavior into it, the packets should be arrive in order.
In any case, TCP would hide the out of order delivery, with either no impact at all or with some re-transmitted packets. So in practice you would not be able to see a difference in TCP behavior on loopback either way.
We have an application doing udp broadcast.
The packet size is mostly higher than the mtu so they will be fragmented.
tcpdump says the packets are all being received but the application doesn't get them all.
The whole stuff isn't happening at all if the mtu is set larger so there isn't fragmentation. (this is our workaround right now - but Germans don't like workarounds)
So it looks like fragmentation is the problem.
But I am not able to understand why and where the packets get lost.
The app developers say they can see the loss of the packets right at the socket they are picking them up. So their application isn't losing the packets.
My questions are:
Where is tcpdump monitoring on linux the device?
Are the packets there already reassembled or is this done later?
How can I debug this issue further?
tcpdump uses libpcap which gets copies of packets very early in the Linux network stack. IP fragment reassembly in the Linux network stack would happen after libpcap (and therefore after tcpdump). Save the pcap and view with Wireshark; it will have better analysis features and will help you find any missing IP fragments (if there are any).
Can anyone tell be where to use the UDP protocol except live streaming of music/video? What are default usecases for UDP?
UDP is also good for broadcast, such as service discovery - finding that newly plugged in printer.
Also of note is that broadcast is anonymous, you don't need to specify target hosts, as such it can form the foundation of a convenient plug-and-play or high-availability network.
UDP is stateless and is good for applications that have large numbers of clients connecting to a server such as time servers or DNS. The fact that no connection has to established and maintained reduces the memory required by the server. There is no handshaking involved and so this reduces the traffic on the network. On the downside, if the information transferred requires multiple packets there is no transmission control to ensure that all packets arrive and in the correct order - but in games packets lost are probably better than late or disordered.
Anything else where you need performance but can survive if a packet gets lost along the way. Multiplayer games come to mind, for example.
A very common use case is DNS, since the overhead of creating a TCP connection would by far outweight the actual payload.
Additional use cases are NTP (network time service) and most video games.
I use UDP to add chat capabilities to our applications. No need to create a server. It is also useful to dispatch events to all users of our applications.
Reading about WCP (woof, what a monster of a subject), and just into the earlier stages of what transports are available. I note that TCP is available, but not UDP. Is this because UDP is not always reliable...lossy with packets ?
Thanks,
Scott
No official reason for that. Who knows may be we will have netUDPBinding in coming releases.
But most probably they gave priority to TCP as it is reliable.
I would certainly think so. UDP is useful for streaming video or audio, not for reliable messaging.