When will one socket suffice, when do I need to create more? - sockets

The "connectionless" aspect of UDP has thrown me for a loop...
If I setup a UDP socket set to INADDR_ANY, then bind that to port 33445 on the local machine, the machine will accept incoming connections from various clients. All of these connections will be serviced by that one socket, since this is not TCP and I cannot spawning a new child sockets to handle each connection directly. I am able to reply to any, some, or all of these connected clients, from their latest message.
So where things get a little fuzzy for me is here...
Am I able to also send out messages at any time to any of these clients? or can I only send messages that in response of recvfrom() ?
Separately, if I wanted that server (while it is serving clients) to connect to another server and have a conversation about something else, I assume I will need to create a new socket for this purpose? I cannot just use the existing server socket and specify a new destination address?
Many thanks to this wonderful community.
Edit: Let me put it another way.. It seems to be that I can only use the bound socket for responding to clients that have previously reached me on that socket. To initiate a conversation with a new host, I cannot simply use the bound socket for that purpose? I must create a new socket in order to reach a server that is listening, correct?

UDP sockets can operate in two different modes:
default not-connected mode: all datagrams sent to the port/address of your process are received; you need to specify destination address for each send you do.
connected mode: only the datagrams sent from the address/port you connected to are received; you don't need to specify destination address on each send.
Here's a small review of connected UDP sockets.
Edit:
Here's a little python UDP server that accepts packets from any client and copies them to a second server. Everything is done with one not-connected UDP socket.
#!/usr/bin/env python
import sys, socket, string
if len( sys.argv ) != 4:
print "Usage: udptee <local-listen-port> <copy-host> <copy-port>"
exit( 1 )
copy = ( sys.argv[2], int( sys.argv[3] ))
s = socket.socket( socket.AF_INET, socket.SOCK_DGRAM )
#s.bind(( 'localhost', int( sys.argv[1] )))
s.bind(( '', int( sys.argv[1] )))
print "listening on ", s.getsockname()
print "copying to", copy
while True:
line, addr = s.recvfrom( 1024 )
print "received: ", line, " from ", addr
s.sendto( line, addr ) # echo to source
s.sendto( line, copy ) # copy to tee
if string.strip( line ) == "exit": break
print "Goodbye and thanks for all the fish"
s.close()
Run it in one terminal as:
~$ ./udptee 9090 <IP-of-copy-server> 9999
Then start netcat in server mode in second term. This one will accept copies of the datagrams:
# this used to be "nc -ul 127.0.0.1 9999" which only listened on loopback
~$ nc -ul 9999
Start netcat client in third term to send stuff to the first server:
~$ nc -u <IP-of-tee-server> 9090
Start typing and see both servers echo what you type.

UDP sockets aren't connected to a remote host or client, so all you need to do is to use sendto() using the destination address and the UDP socket you have initialized. So yes, you can send out messages using the UDP socket at any time given that you have set up the UDP socket correctly. Just set the receiving address in the sockaddr struct you are using. If the receiving part have a UDP socket bound on the port you are sending the message, then it will receive it.
On that 2nd question it all depends if the conversation with that 2nd server uses a different port. If it uses the same port then there is no need to create another UDP socket. You just have to separate the messages the server 1 gets from its clients from messages it gets from server 2 somehow.
Ill recommend taking a look at Beej's excellent guide chapter 5.8 and 6.3.
Beej's Guide to Network Programming

Related

Purported UDP "connection"

My understanding was that UDP doesn't form connections; it just blindly sends packets. However, when I run
nc -u -l 10002
and
nc -u 127.0.0.1 10002
simultaneously (and so can send messages back and forth between terminals), lsof reports two open UDP connections:
nc ... UDP localhost:10002->localhost:35311
nc ... UDP localhost:35311->localhost:10002
If I open a third terminal and do nc -u 127.0.0.1 10002 again, to send another message to the original listener, the listener does not receive (or acknowledge, at least) the message, suggesting it is indeed tied to a specific connection.
If I implement a UDP echo server in Java like this and do sorta the same thing (on 10001), I get
java ... UDP *:10001
nc ... UDP localhost:52295->localhost:10001
aka, Java is just listening on 10001, but nc has formed a connection.
Based on my understanding of UDP, I'd expect both sides to behave like the Java version. What's going on? Can I make the Java version do whatever nc is doing? Is there a benefit to doing so?
I'm on Ubuntu 20.04.3 LTS.
UDP sockets can be connected (after a call to connect) or they can be unconnected. In the first case the socket can only exchange data with the connected peer, while in the second case it can exchange data with arbitrary peers. What you see in lsof is if the socket is connected or not.
My understanding was that UDP doesn't form connections; it just blindly sends packets.
That's a different meaning of the term connection here. TCP has always "real" connections, i.e. an association between two endpoints which has a clear start (SYN based handshake) and end (FIN based teardown). TCP sockets used for data exchange are therefor always connected.
UDP can have associations between two endpoints too, i.e. it can have connected sockets. There is no explicit setup and teardown of such a connection though. And UDP sockets don't need to be connected. From looking at the traffic it can therefore not be determined if connected UDP sockets are in use or unconnected.
Can I make the Java version do whatever nc is doing?
Yes, see What does Java's UDP DatagramSocket.connect() do?
.
Is there a benefit to doing so?
An unconnected UDP socket will receive data from any peer and the application has to check for each received datagram where they came from and if they should be accepted. A connected UDP socket will only receive data from the connected peer, i.e. no checks in the application are needed to check this.
Apart from that it might scale better if different sockets are used for communication with different peers. But if only few packets are exchanged with each peer and/or if one need to communicate with lots of peers at the same time, then using multiple connected sockets instead of a single unconnected one might mean too much overhead.

Is sending ACK back on TCP/IP software or hardware thing?

How do we know port is listening?
Is there possible to know that port is listening, even if they do not respond?
i.e. when I just bind socket in some programs, but I really do not send ACK back.
1: Packet is received and analyzed.
2: If packet fit meets, ACK is send back.
Like if I can program this thing, or it's networks card HW that is responsible for ACK.
How do we know port is listening?
Your local stack knows. An application needs to register the port.
Is there possible to know that port is listening, even if they do not respond?
If there's no reponse to a SYN sent out the host may be unreachable, the destination port not listening, or the SYN filtered.
i.e. when I just bind socket in some programs, but I really do not send ACK back.
You don't have to worry about SYN and ACK, that's handled by the OS's IP stack. Just set up a listener on destination and then connect the socket from source. If the socket opens you can start talking through the pipe.
Like if I can program this thing, or it's networks card HW that is responsible for ACK.
ACKs are part of the TCP transport protocol handled by the OS's IP stack.
You can find out the list of sockets and connections using netstat command. Use netstat -a and grep for the port in question. You can find out if there is a socket listening on the port you want.

Using SO_REUSEPORT to simulate stateful UDP

I am building a p2p application in which every peer can maintain a connection with multiple other peers.
Maintaining a connection is easy with TCP. I have a server listening on a specific port on every node. Whenver peerA wants to connect to peerB, it creates a socket and makes a connect call to the listening port of peerB. This creates a new socket on which both the peers can do all their subsequent conversation on.
I want to simulate the same concept of workflow in UDP. Something similar to this question The traditional way of conversing with multiple peers on UDP from what I found is that every peer is listening on a predefined port. Every sendTo call specifies the ip and port of the peer we want to connect to and on the receiver side, we use recvFrom to handle it based on which peer it is coming from (e.g. passing the msg to a thread which handles messages from that specific peer).
However, I wanted to know if there is any way of doing the same without the need to demultiplex at the receiver. I found the SO_REUSEPORT flag can be used to implement this http://man7.org/linux/man-pages/man7/socket.7.html
https://lwn.net/Articles/542629/.
Basically, SO_REUSEPORT allows multiple sockets call bind on the same port. So, I bind a server port similarly as before. However, when I get a connection from a new peer, I bind a new socket to the same port and call connect on the sender's address. Then I pass this new socket to a thread which listens to messages from the sender.
makeListeningSocket ip port = do
sock <- socket ip port
setSocketOption sock ReusePort 1
bind sock
return sock
runUDPServer sock = do
(receivedMessage, peerAddr) <- recvFrom sock 4096
newSock <- makeListeningSocket "0.0.0.0" 3001
connect newSock peerAddr
async (readMessagesFromSock newSock)
runUDPServer sock
I was able to make this approach work. However, SO_REUSEPORT option doesn't seem to be created with this specific use case in mind. So my question is, is there anything horribly wrong with using SO_REUSEPORT in this manner which I am not able to see? Are there better ways of doing this?

Communication protocols in UDP

After many hours, I have discovered that the given udp server needs the following steps for a successful communication:
1- Send "Start Message" on a given port
2- Wait to receive from server on any port
3- Then the port dedicated to you to send further data to the server equals the port you have received on it + 1
So I am asking if this kind is a known protocol/handshaking, or it is only special to this server??
PS: All above communication were in udp sockets in C#
PS: Related to a previous question: About C# UDP Sockets
Thanks
There's no special "handshake" for UDP -- each UDP service, if it needs one, specifies its own. Usually, though, a server doesn't expect the client to be able to listen on all of its ports simultaneously. If you mean that the client expects a message from any port on the server, to the port the client sent the start message from, then that makes a lot more sense -- and is very close to how TFTP works. (The only difference i'm seeing so far, is that TFTP doesn't do the "+ 1".)
The server is, effectively, listening on a 'well known port' and then switching subsequent communications to a dedicated port per client. Requiring the client to send to the port + 1 is a little strange
Client 192.168.0.1 - port 12121 ------------------------> Server 192.168.0.2 - port 5050
Client 192.168.0.1 - port 12121 <------------------------ Server 192.168.0.2 - port 23232
Client 192.168.0.1 - port 12121 ------------------------> Server 192.168.0.2 - port 23232 + 1
<------------------------ Server 192.168.0.2 - port 23232
------------------------> Server 192.168.0.2 - port 23232 + 1
The server probably does this so that it doesn't have to demultiplex the inbound client data based on the client's address/port. Doing it this way is a little more efficient (generally) and also has some advantages, depending on the design of the server, as on the server there's a 'dedicated' socket for you which means that if they're doing overlapped I/O then the socket stays the same for the whole period of communications with you which can make it easier and more efficient to associate data with the socket (this way they can probably avoid any lookups or locking to process each datagram). Anyway, enough of that (see here, if you want to know why I do it that way).
From your point of view as a client (and I'm assuming async sockets here) you need to first Bind() your local socket (just use INADDR_ANY and 0 to allow the OS to pick the port for you) then issue a RecvFrom() on the socket (so there's no race between you sending data to the server on this socket and it sending you data back before you issue a recv). Then issue a SendTo() to the 'well known port' of the server. The server will then send you back some data and your RecvFrom() will return you the data and the address that the server sent to you from. You can then take that address, add one to the port, store that address and from then on issue SendTo()s to that new sending address whilst continuing to issue RecvFrom()s for reading the server's data; or you could do something clever with Connect() to bind the remote end of the socket to the server's 'send to address' and simply use Write() and RecvFrom() from then on.

General sockets UDP programming question

I have an FPGA device with which my code needs to talk. The protocol is as follows:
I send a single non-zero byte (UDP) to turn on a feature. The FPGA board then begins spewing data on the port from which I sent.
Do you see my dilemma? I know which port I sent the message to, but I do not know from which port I sent (is this port not typically chosen automatically by the OS?).
My best guess for what I'm supposed to do is create a socket with the destination IP and port number and then reuse the socket for receiving. If I do so, will it already be set up to listen on the port from which I sent the original message?
Also, for your information, variations of this code will be written in Python and C#. I can look up specific API's as both follow the BSD socket model.
This is exactly what connect(2) and getsockname(2) are for. As a bonus for connecting the UDP socket you will not have to specify the destination address/port on each send, you will be able to discover unavailable destination port (the ICMP reply from the target will manifest as error on the next send instead of being dropped), and your OS will not have to implicitly connect and disconnect the UDP socket on each send saving some cycles.
You can bind a socket to a specific port, check man bind
you can bind the socket to get the desired port.
The only problem with doing that is that you won't be able to run more then one instance of your program at a time on a computer.
You're using UDP to send/receive data. Simply create a new UDP socket and bind to your desired interface / port. Then instruct your FPGA program to send UDP packets back to the port you bound to. UDP does not require you to listen/set up connections. (only required with TCP)