Communication protocols in UDP

Question

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: http://stackoverflow.com/questions/2757868/about-c-udp-sockets

Thanks

Answer 1

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

Answer 2

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.