Networking with UDP, should I keep sockets open on the server

Question

I am working on making a 2D platforming game that will have multiplayer functionality. Over the last few days, I have done a lot of reading regarding how to deal with the networking, and believe that I am on the way to implementing some of the concepts I have read about.

I have decided to go with an Authoritative server/client model, where multiple clients will send actions made by the user to the server, client will predict the players next steps before comparing against the Authoritative reply from the server, etc. This seems to have been suggested in numerous corners of the web regarding games networking, and seems reasonable.

Before jumping straight into trying to get snapshots sent from the server, I wanted to make sure that I had an idea of some of the technical nuances of a language, as conceptual knowledge can only get me so far. I have set up a simple Echo Server that has worked rather well for a single client, but now my next step is to have multiple clients connected to the server at a single moment, and have each message that is sent from a client echoed to all clients connected to the server.

I feel that the answer might be language dependent, so I will mention now that currently I am using Java for the networking (a little bit of preliminary testing may suggest that Java has significant overhead in its network implementation, so I am open to change upon suggestion). I am using UDP for speed sake (and this seems to be what is predominantly suggested).

My question is with the server, should I be keeping each DatagramSocket that represents a connected client open and send DatagramPackets directly out without ever closing them (until the program terminates, client disconnects, etc.), and have them stored in some form of Collection, or should I close them after each message is sent and create a new outgoing socket whenever I need to send a packet? There are obvious performance disadvantages of creating a socket whenever I need to send a message, but is there some fundamental reason that I have not come across that suggests leaving sockets open is not a good idea?

Answer 1

You should be able to use java without any performance problems, the technology went way past that. Although services that work with massive number of clients still use c++.

As for your choice of sockets, it's not a matter of performance, as people usually think, it's about what are you going to use them for.
On game servers you don't care if messages are out of order or got lost, you just want updates going as fast as possible. Lost messages can be ignored and if you get messages in order: 1 2 4 3, you just ignore message 3, because you already got the newer update (4). In this case you use UDP sockets (which is actually a simple wrapper over internet protocol (IP)).
But on the web you want all the content to arrive in order. You don't want the footer of your .html page to be processed before the header, or to lose part of the .html page with the closing tags, because it would screw up everything, neither do you want to get second frame of your youtube video before the first one. So here you use TCP sockets that will rearrange the packets as they come to be in order and resend the request for parts that were lost (this is also a wrapper over IP, but it has a lot of optimization and features developed over past 30 years).

Many applications use both TCP and UDP on the same port, which is pretty handy, but if you're making a game server and want to make sure the "attack" command gets to the server when client on the mouse you would be better off implementing it using the same UDP socket you use for updates.

As for how to implement this, my practice is to have a single socket on the server that would receive all the requests and send all the responses (don't process the requests in the same thread that receives them). And identify the clients by their IPEndPoint (plus whatever type of token you use for security, if any). Just remember the IPEndPoint of the clients, so you know where to send the response, or in case you need to send them something asynchronously.

Making a new sockets for each client is something you do with TCP, when you use TCPListener. But UDP sockets aren't bound to any client, so making a new sockets for each client is useless, it just means you'll have to bind a lot of ports (and setup port forwarding for all ports to your computer if you're behind a router).

Answer 2

In client-server architecture, server is said to be always listening to its port(s) so that any client can connect to it at anytime. Also, clients usually have dynamic IP addresses and the port used for the connection may vary from machine to machine; on the other hand, servers should have static IPs (at least, DNS translation helps us) and the port(s) used to connect to them should be known to the clients.

That said, if you want to deal with one socket per client, you can set a main socket that listens to a "server port", through which a connecting client can tell the server its own IP address and the port it is using for the connection. Such socket just listens to incoming messages, and when a new connection request arrives the server creates another socket on a different port, and tells the client that communication is possible by using the same server IP but on our new socket (which listens to a different port than "server port").

Note that this client-server communication is not a real connection: clients just know they can send messages to the server and that such messages are likely to be received by it, and viceversa. Server should be keeping a list of clients' IPs and ports (one can use a dynamic Array, a data structure...) in order to track them and send packets when needed, as well as checking for clients' status or more.