Udp protocol for game server/client

Question

I've been trying to get a simple client server relation using udp for about a week now, And I think it's time for me to stop trying and ask for help... I understand how TCP works and UDP too. The thing is, when I use UDP, there's no way for me to know the client is still connected, and same thing for the client. I tried using two connections, one TCP for sending important data such as login information, but I don't know how to keep a stable connection in UDP!

Here's how I work:

1. The server starts a new thread for listening on port X with TCP
2. The client connects to the server in TCP using the port X
3. The server sends a confirmation for connection on the UDP part of the server
4. The client starts sending information (location of the player) via udp and opens a thread for that client (tcp and udp).
5. When the server hasn't received data for 15 seconds, it sends a "ping"
6. If the server hasn't received "pong" in the next 5 seconds, it closes the connection + thread for this client.
7. When a client is disconnected or sends a disconnect packet, it closes the connection + thread for this client.

The main problem with this is that I don't know how to receive data(server side) from a certain address via udp. At the moment, I can only receive data from every address...

Is there a way I could ensure I only receive data from a single remote computer (on the listening thread of that particular client)? Am I doing something wrong? Should work differently (seems it's making lots of connections and threads for a server that would have lots of clients)?

I'm working in C# with console applications at the moment, but I'll be using forms in the future, and the game is going to be in Java (C# XNA 4.0 for testing the connection first).

And most important of all, Thanks you!

Answer 1

You can't route particular clients to particular threads automatically. You would need to open a different UDP port for each client and listen on a particular port on only one thread.

This really isn't ideal, though. Open a single listening UDP socket on a single thread and do all of your networking there. You can generate messages to other threads if your game actually needs other threads for processing (you probably don't). It's more common to have a single thread for receiving and sending network packets and then another for all your game logic, so you can easily get away with a pair of concurrent queues (one for pushing network messages into to be sent by the network thread, and one filled by the networking thread with incoming packets for your logic thread to process).

Java (and to a lesser extend, C#) try to make you think of using threads for everything but you really really shouldn't. USe them to process large parallel workloads, not to do I/O multiplexing. Especially when the very nature of the protocol being used (UDP) is designed to handle multiple clients on a single server socket.

You don't need multiple UDP sockets for each client as you can retrieve the client endpoint (address + port) when reading any packet from a UDP socket. You can use this endpoint to map to client status objects.

On an unrelated note, using TCP to initialize the connection is not super ideal. One of the primary problems is that a client behind most NAT firewalls will not be able to receive data on a UDP port unless the client sends outgoing data on that port. Better to just have a single incoming UDP port and use UDP requests from the client to initialize things.