Greetings, this is my first post here so excuse me if I ask or say something stupid. :)
I am working on a multiplayer game and I am putting together a prototype implementation of the back end. I will be using UDP to provide support for the realtime aspects of the player interraction and I am having something of an internal dilemma. There are two different ways I could implement the realtime aspects and I am having trouble deciding between the two and would appreciate some opinions especially from those with experience.
Option 1:
I can have a single server listener on a particular socket that recieves UDP messages and then has a HashMap of actual destinations inside the server. As a message comes in, it gets routed to the correct processor for that player using the encoded player id to identify the correct destination. The pros to this is that the implementation is relatively straightforward on the server side. My concerns is that the single port will become innundated with tens of thousands of packets per second and cause a bottleneck in processing. Also the routing algorithm itself, while very fast even in Java, will introduce some overhead as well. The overhead with the HashMap implementation should be O(1) but should not be entirely dismissed.
Option 2:
I can create a complex system whereby the client sends udp messages to a particular port provided by the server and there is a server directly listening to that port. This would have the benefit of allowing the underlying IP protocol to do the routing and that would possibly be faster than the hash map implementation. Each player would have one of X number of dedicated ports to send UDP messages to and no post recieve routing would have to take place.
Option 3:
Go for a hybrid system where there are many possible open ports and each open port will handle n clients.
Common:
In either case the server will send data to the client on a single UDP port that the client has opened through the firewall (though I havent investigated how well this works with console systems). Since there would be no need of routing on the client side this should be efficient. Also there is a possibility, due to load balancing, that i might have to redirect the clients to connect to other servers in the cluster. That can be done with a UDP message changing the destination for client messages.
Other Concerns:
I have already discounted TCP as being inappropriate for this application since strong realtime concurrency is required and old packets are irrelevant.
However, I would also like to find some way to encrypt the data stream between the client and server, possibly using Fast AES in a manner similar to the HTTPS handshake protocol. This would introduce decrypt overhead and put more pressure on the CPU resources of the single router.
Any opinions on the preferred strategy (especially if you have actual experience with the downfalls and benefits of implementing the strategies) would be appreciated.