Jump to content

  • Log In with Google      Sign In   
  • Create Account



Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
4 replies to this topic

#1 OzgurEra   Members   -  Reputation: 678

Like
0Likes
Like

Posted 07 December 2012 - 05:45 PM

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.


Sponsor:

#2 0BZEN   Crossbones+   -  Reputation: 2013

Like
1Likes
Like

Posted 07 December 2012 - 06:10 PM

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.

Everything is better with Metal.


#3 OzgurEra   Members   -  Reputation: 678

Like
0Likes
Like

Posted 07 December 2012 - 06:35 PM

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 :)

#4 0BZEN   Crossbones+   -  Reputation: 2013

Like
0Likes
Like

Posted 07 December 2012 - 09:52 PM

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.

Everything is better with Metal.


#5 hplus0603   Moderators   -  Reputation: 5185

Like
0Likes
Like

Posted 08 December 2012 - 11:06 AM

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.
enum Bool { True, False, FileNotFound };




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS