   udp recvfrom returns 0
  I'm talking to my server using udp sockets on linux. The server works fine as it's been talking to my other apps for literally years. So I wanted to create a mini linux udp app that just sends a request to the server and loops around receiving responses that are sent every half a second. So I send the request off - the server sends responses  that I can see every half a second - visible using wireshark. The recvfrom calls returns every half a second BUT - it is returning a 0 each time. Now in tcp this means the other end has gracefully closed down - but in udp it should return either the length of the data or a -1 for error. So what's causing it to return a 0 ? As I say you can see the packet being sent from my server to me on wireshark.   
  From the manpage for recv/recvfrom/recvmsg"RETURN VALUE  These  calls  return  the  number  of bytes received, or -1 if an error occurred.  The return value will be 0 when the peer  has  performed  an   orderly shutdown.";  for tcp returning a 0 means an orderly shutdown has taken place. For udp there is no connection to shut down. Also we can see the packets containing good data being sent every half a second.   ;  "For udp there is no connection to shut down."That's not necessarily the case; You can send UDP data down a connected socket. That's how recvmsg doesn't need any address information.Is it possible that someone (even another process) is closing the socket somewhere and it is lingering, and hence trying to read from the socket using the non-connection protocol is producing the "was shutdown" error case?;  There is no "lingering" state for an UDP socket. There is no "orderly" shutdown on the remote side of a UDP conversation. The best you can do is to get "ICMP no such port" if the other end closes their UDP socket."Connected" UDP sockets are purely a client-side implementation detail, used as a shorthand for certain addressing use patterns.If recv()/recvfrom() returns 0, I would assume that it got a 0-size UDP datagram. In UDP, such messages are possible, as opposed to TCP.   ;  "There is no "lingering" state for an UDP socket. "No, but there is a linger state for a TCP connection which could be occupying the socket... hence wondering if someone/something else had established a connection and then closed it leaving the thing in linger.The zero length packet thing I'd forgotten about though :-){Although the OP says they can see valid data on the wire..};Quote:No, but there is a linger state for a TCP connection which could be occupying the socket... No, a socket cannot be both TCP and UDP. A socket also cannot "take over" another existing socket, unless you use file handle/descriptor inheritance and start sub-processes that inherit the sockets.Finally, if you're confusing "sockets" with "ports," then the TCP port space is totally different from the UDP port space. Think of them as different streets. Just because you live on 1234, TCP street, doesn't mean that you have anything to do with, or will see any traffic to, someone living on 1234, UDP street.The protocol selector field is actually part of the address in IP terms, it's just not visible in an IPv4 address struct, because it's implicit in what kind of socket you create. This conflation of "port" into sockaddr_inet is a poor design decision made 40 years ago that's still with us today...