Udp sockets

Hello everyone!
I just joined this forum and I was wondering if anyone could help me with a udp problem. Im trying to make a pong multiplayer game using c++/sdl lib and winsock udp sockets. My question relates to udp and how can I construct it to handle 2 clients that send messages to the server where the data is resent to both clients. I already managed to make a udp server and a client however Im not sure how to go about making it possible for the server to handle 2+ clients at a time. Do I need threads?

Thank you.

Theoretically, a UDP server does not need to multithread.

Let's assume that the server has one UDP socket and both clients send to that same socket:
Server creates socket and waits to read something.
Client 1 sends a datagram.
Server reads it, processes it, and sends response to Client 1.
Client 2 sends a datagram.
Server reads it, processes it, and sends response to Client 2.
Client 1 sends a datagram.
Server reads it, processes it, and sends response to Client 1.
Client 1 sends a datagram.
Server reads it, processes it, and sends response to Client 1.

and so on

Of course, in order to run the game the server must know whether it's just heard from Client 1 or 2. Off the top of my head, I would think you might:

1. Embed the client's ID inside the datagram packet.

or

2. Have each client register with the server to join in a game. Part of that registration process would have the server save the client's sockaddr_in. Then when a datagram comes in the server can compare the datagram's sockaddr_in with the ones for the clients who have registered.

Regardless of which approach you use, the server will use the client sockaddr_in it got from the recvfrom call to know where to sendto the response to.


Now, if you want the server to also perform background tasks while waiting for a datagram, then you could use select or non-blocking sockets. For that matter, even if you were using TCP you could still avoid multithreading by using select or non-blocking sockets.

DWise1's Sockets Programming Page:
Dealing With and Getting Around Blocking Sockets
http://members.aol.com/DSC30574/sockets/blocking.html

Ok, thanks. I still have one question however.

What if both clients send the data at the same time? Will it be handled correctly by the server? (both clients' messages will be received by the server)

The thing with a UDP (connectionless) socket is to use "sendto" and "recvfrom" instead of "send" and "recv". "recvfrom" will supply you with the address of the sender (presuming the proper protocol); you "sendto" that address with the reply.

Using TCP would require a connection (socket) for each client, but in a pong game (two clients) that would not be onerous. In your application, I would call it a tossup.

I can't think of why not. The packets should queue up in the receive buffer. I guess that if that buffer were to fill up then you'd start dropping packets, but I don't think that should be a problem during normal operation.

As I'm sure you know, tcp guarantees delivery, so if a tcp packet gets dropped or corrupted then the receiver requests a retransmission. You don't have that in udp, which is essentially sendto-and-forget. Any guarantees of delivery must be implemented by the application. Your application protocol (ie, how the applications communicate with each other) could do this in a number of ways; eg:

1. Require handshaking in which the receiver will ACK or NAK within a certain period of time to let the sender know that the packet had arrived; if the sender times out then it didn't arrive and the sender resends. To avoid duplicate packets being received by accident, they should have a sequence field.

2. Some protocols, like TFTP, rely on sequence fields to ensure that all packets are received and pieced back together in the right order.

3. Or a client might always expect a response from the server. If it times out then it tries again.

Ok thanks, I managed to make the server register clients and resend all data that comes in.

Im testing my game on LAN (two clients, one server). I noticed that when one client (client #1) sends a packet it always reseives it back however the other client(client #2) receives packets (of client #1) about 90% of the time.

Is it normal for a client to be guaranteed to receive its own packets from the server?

Also, I thought LAN network never loses packets. Am I wrong? If not, then how come client#2 does not receive all packets that were sent to the server by client#1?

Thank you :-]

Nope. TCP/IP has several protocols. Each has its advantages and disadvantages.

TCP is a reliable transport protocol, which means that the OS takes care of ensuring that packets don't get lost and they arrive in the same sequence that they were sent out and so on. Of course, the OS cannot guarantee success (for instance, if the wire gets cut or the other end crashes), but it tries its best to deliver the packets. Say if 3 packets are sent and the 2nd one doesn't make it to the other end, TCP will automatically resend the second packet until the other end acknowledges it has received it. The other end will then take the three packets and put them in a proper sequence and deliver it to the listening application. What this means is that if your application uses TCP, then it doesn't need to worry about checking if packets have been lost or arrived out of sequence, since that job is done by the OS. All that your application has to do is hand off the data to send to the OS and let it handle the complicated stuff. Naturally, using TCP means there is some extra overhead involved on both sides to ensure reliable delivery.

UDP is an unreliable transport protocol. In this case, the OS merely transmits and receives packets, but won't check if a packet got lost somewhere or if they've arrived out of sequence. Instead, it leaves that logic to the application to figure it out. This means that there is less overhead in sending and receiving data, but the OS doesn't guarantee any reliability and lets your application handle it.