In our application we have UDP socket(s) that are used only to send packets (these sockets are never read, and never bound to a port). The sockets are "connected" to the destination address. Are there messages like ICMP etc that could conceivably be directed back at these ports and delivered to the receive buffers of these sockets? If so for what types of messages would this occur?
(these sockets are never read, and never bound to a port).
They are bound to a port when you call connect() if not already bound.
Are there messages like ICMP etc that could conceivably be directed back at these ports
Yes. ICMP UNREACHABLE for a start.
and delivered to the receive buffers of these sockets?
No. ICMP UNREACHABLE will cause an exception next time you use the socket.
If so for what types of messages would this occur?
None. If you are getting data in the socket send buffer, someone is sending you UDP datagrams. In fact the connect target is sending you UDP a datagrams.
Related
For my UDP application I want to spread the handling per session (4 tuple) over to different threads. But looks like if there are multiple server sockets (bind calls) for unicast packets kernel will deliver the packet only to one of the threads.
Is this the behavior always or are there any config knobs to enable per session routing of the incoming packets to different sockets ?
Pointer to the relevant functions in the kernel code that delivers the incoming packet to the socket will also be helpful.
Thanks.
But looks like if there are multiple server sockets (bind calls) for unicast packets kernel will deliver the packet only to one of the threads.
This is correct, the packet will only be delivered to one socket.
... enable per session routing of the incoming packets to different sockets ?
There are no sessions in UDP and thus no per sessions routing.
It is possible though to connect UDP sockets, i.e. call both bind and connect. In this case the packet will be delivered to the connected socket. If there are multiple connected sockets for the same source it will again be delivered to only one. And note that a connected socket will only receive packets for this connection, i.e. not from arbitrary sources like an unconnected socket.
Pointer to the relevant functions in the kernel code that delivers the incoming packet to the socket will also be helpful.
This behavior is not specific to Linux.
I'm writing a network program using SFML, and as my understanding was, UDP sockets are utterly connection-less
When i try read from my socket, I'm getting a "Disconnected" error code, but the documentation doesn't seem to mention UDP sockets being able to return this kind of error (only TCP ones being able to)
What could a UDP socket being Disconnected possibly mean?
While UDP as a protocol is "connectionless", the socket APIs support virtual connections to allow connection oriented functions to continue to work. When you call connect on a UDP socket, the OS remembers the connection data you set just as it normally would and it filters things that are not consistent with the virtual connection, this allows you to use interfaces like recv, send and getpeername because the peer is implicit. If you don't use connect, then you need to use interfaces like sendmsg. sendto, recvmsg and recvfrom where the peer is being communicated on a per packet basis.
In the case of SFML, it isn't necessarily using something that needs a connection, though, it is remapping other errors such as timeouts to Disconnected.
I am building an application that will deploy in effect on multiple "clients" with a common "server". Clearly I could communicate between each client and the server using a single read-write socket for each client-server link, or a read socket and a write socket per link if I really wanted to.
But what if there are (hopefully good) reasons that the server wants to read from any client, and broadcast back to all? If you have a connectionless protocol like UDP, can the server use only a single read-write socket, or must it use one for reading and one for writing? What about the clients? And does this change if you use a connection-based protocol like TCP?
If you have a connectionless protocol like UDP, can the server use only a single read-write socket, or must it use one for reading and one for writing? What about the clients? And does this change if you use a connection-based protocol like TCP?
A socket as an endpoint which has at least a local address and port in case of UDP and TCP. Only data received for this ip and port are delivered to the socket and all data send from this socket contain the local ip and port as the source. A socket can be connected, in which case also the destination IP and port is known. With TCP a socket needs to be connected, with UDP not.
This means:
You can use the same unconnected UDP socket to send data to multiple peers (destination is an argument for the sendto function). You cannot do this with TCP, i.e. you need a connected socket for each single peer.
You can receive data from multiple peers on an unconnected UDP socket. You cannot do this with TCP.
The special broadcast address can be used with UDP but not with TCP, since with TCP you need to have a connection between only two clients which is not the case with broadcast.
See also a related question with answer for more information: Bidirectional UDP Multicast
But what if there are (hopefully good) reasons that the server wants
to read from any client, and broadcast back to all?
Well, then you'd probably want to use a UDP socket (either instead of, or in addition to, some TCP sockets) :)
If you have a connectionless protocol like UDP, can the server use
only a single read-write socket, or must it use one for reading and
one for writing?
A single UDP socket is sufficient for both reading and writing (although some multithreaded designs might find it easier to use two separate sockets instead; either way will work).
What about the clients?
Clients can also use a single socket for both sending and receive UDP packets, if that's what you're asking.
And does this change if you use a connection-based protocol like TCP?
With TCP sockets you can also use a single socket for both sending and receiving. However you will need one TCP socket for each destination that you want to send or receive to/from. (Contrast this with UDP where a single UDP socket can be used in conjunction with sendto() or recvfrom() to communicate with multiple peers)
As per your requirement, you have two ways :
By using TCP connection only : Server reads message from client and for the broadcasting to all clients,server writes message to all client's TCP sockets(connected to clients) and clients read that message from TCP socket(connected to server).This method requires that client and server knows the IP addresses of each other
By using TCP connection for the client-server direct communication and UDP for broadcasting : In this method,client and server communicates (directly one to one) using TCP connection. For broadcasting the message, server can broadcast the message over the network using UDP socket and clients have UDP broadcast receiver for receiving the broadcast message.
Can a Client pushing data through a UNIX domain socket ( AF_UNIX type ) be signaled busy if the receiving end cannot cope with the load?
OR
Must there be a Client-Server protocol on top of the socket to handle flow control?
You can definitely do a blocking send to a UNIX Domain socket. If the receiving side's receive buffer is full, or if the number of outstanding (undelivered) send socket buffers is too high, the sender will block.
SOCK_STREAM UNIX Domain Sockets work like TCP sockets. SOCK_DGRAM UNIX Domain Sockets work like UDP, except that UNIX Domain datagrams have guaranteed, in-order delivery, whereas UDP sockets can be re-ordered or dropped. (Also, UNIX Domain Sockets can be used to send file descriptors and pass user credentials between processes, neither of which can be done with TCP, UDP, or pipes.)
So, because in-order delivery is guaranteed by all types of UNIX Domain Sockets, the receiver can just stop receiving when it is busy doing other things, and the sender will be automatically blocked when there's no more buffer space available (or will be notified that there's no more buffer space, if they requested non-blocking operation on their socket). Then, when the receiver starts receiving again, the sender will be allowed to send more.
Unless you include this in the protocol, there is no way for the server to tell the client to pause sending the information.
Other than the server having some knowledge of when it is 'busy' and sending a specific signal back (e.g. HTTP's 503 Service Unavailable). You can also set up the client side connection to timeout after a certain length of time, and if you get a timeout event, interpret that as the server is busy.
UDP doesnot sends any ack back, but will it send any response?
I have set up client server UDP program. If I give client to send data to non existent server then will client receive any response?
My assumption is as;
Client -->Broadcast server address (ARP)
Server --> Reply to client with its mac address(ARP)
Client sends data to server (UDP)
In any case Client will only receive ARP response. If server exists or not it will not get any UDP response?
Client is using sendto function to send data. We can get error information after sendto call.
So my question is how this info is available when client doesn't get any response.
Error code can be get from WSAGetLastError.
I tried to send data to non existent host and sendto call succeeded . As per documentation it should fail with return value SOCKET_ERROR.
Any thoughts??
You can never receive an error, or notice for a UDP packet that did not reach destination.
The sendto call didn't fail. The datagram was sent to the destination.
The recipient of the datagram or some router on the way to it might return an error response (host unreachable, port unreachable, TTL exceeded). But the sendto call will be history by the time your system receives it. Some operating systems do provide a way to find out this occurred, often with a getsockopt call. But since you can't rely on getting an error reply anyway since it depends on network conditions you have no control over, it's generally best to ignore it.
Sensible protocols layered on top of UDP use replies. If you don't get a reply, then either the other end didn't get your datagram or the reply didn't make it back to you.
"UDP is a simpler message-based connectionless protocol. In connectionless protocols, there is no effort made to set up a dedicated end-to-end connection. Communication is achieved by transmitting information in one direction, from source to destination without checking to see if the destination is still there, or if it is prepared to receive the information."
The machine to which you're sending packets may reply with an ICMP UDP port unreachable message.
The UDP protocol is implemented on top of IP. You send UDP packets to hosts identified by IP addresses, not MAC addresses.
And as pointed out, UDP itself will not send a reply, you will have to add code to do that yourself. Then you will have to add code to expect the reply, and take the proper action if the response is lost (typically resend on a timer, until you decide the other end is "dead"), and so on.
If you need reliable UDP as in ordering or verification such that TCP/IP will give you take a look at RUDP or Reliable UDP. Sometimes you do need verification but a mixture of UDP and TCP can be held up on the TCP reliability causing a bottleneck.
For most large scale MMO's for isntance UDP and Reliablity UDP are the means of communication and reliability. All RUDP does is add a smaller portion of TCP/IP to validate and order certain messages but not all.
A common game development networking library is Raknet which has this built in.
RUDP
http://www.javvin.com/protocolRUDP.html
An example of RUDP using Raknet and Python
http://pyraknet.slowchop.com/