4 replies to this topic

[FreOzgur]

First of all sorry for my bad English..

I have a question about UDP sockets..

I have used TCP lots of times, and when I need to create a multi-client server, I create a Client class, and call a Receive function which calls "recv" using its socket number.. So I can easily read data that related to this client from socket..

But now, I want to use UDP..
in UDP, there is no socket numbers as in TCP.. I use recvfrom and it gives me a address.. How can I bind an address to a Client (a pointer)..
When a data received, how can I know whose data is this?

Do I have to create a table like hashtable? Or is there any methods that commonly used to handle hundreds of client ?

Edited by FreOzgur, 07 December 2012 - 05:47 PM.

[papalazaru]

First of all sorry for my bad English..

I have a question about UDP sockets..

I have used TCP lots of times, and when I need to create a multi-client server, I create a Client class, and call a Receive function which calls "recv" using its socket number.. So I can easily read data that related to this client from socket..

But now, I want to use UDP..
in UDP, there is no socket numbers as in TCP.. I use recvfrom and it gives me a address.. How can I bind an address to a Client (a pointer)..
When a data received, how can I know whose data is this?

Simply by the client address and port from the recvfrom(). These will be unique to each client. With IPV4, the address will be a single u32, the port a u16.

Do I have to create a table like hashtable?

Can do. You just need a method to link an ip+port to one of your client proxy, whichever method is most efficient. You can call this an address map

Or is there any methods that commonly used to handle hundreds of client ?

Often, you will have a handshake protocol when a client wants to connect to a server. Then the server can assign a number (ticket) to each client. The ticket can be a simple index into a table that you can quickly look up by reading that number off the client packet. You can also do a sanity check on the address, for example making sure the ticket is not getting 'spoofed' by another client.

[FreOzgur]

Often, you will have a handshake protocol when a client wants to connect to a server. Then the server can assign a number (ticket) to each client. The ticket can be a simple index into a table that you can quickly look up by reading that number off the client packet. You can also do a sanity check on the address, for example making sure the ticket is not getting 'spoofed' by another client.

Wow thanks,, that was what is on my mind

[papalazaru]

Yeah, it means you will add a little overhead on packets (say, one byte, for a maximum of 256 clients). in a peer-to-peer star configuration, 16 players, 20 fps that's 8 bits * 20 * 15 = 2.5 kbits/s. That's about one percent of the total traffic on average (tabbing on a 256 kbit/s maximum game bandwidth).

For a pure client-server architecture, most of the bandwidth load will be from server->client, the client->server traffic is usually much, much less, and then the overhead (since only clients need to communicate their ticket back to the server) is statistically insignificant.

Edited by papalazaru, 07 December 2012 - 09:55 PM.

[hplus0603]

you will add a little overhead on packets (say, one byte, for a maximum of 256 clients).

You don't have to. The remote client will use some ip address/udp port combination, and will keep using that for the duration of the session. This stays true using NAT, too.