Sign in to follow this  

Main Server sending list of Host's

This topic is 3460 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

My setup is strictly UDP. The player will send a "HOST LIST" request to the server and stops once he starts getting data, only thing is I dont know how I should send data. Meaning there could be 400 host players, each having a name and some map characteristics. Should I send info one at a time, or all at once, I just dont know what to do about this cuz its alot of data.

Share this post


Link to post
Share on other sites
The maximum packet size for UDP is like 64k bytes I think.

//edit Also check out reliable UDP. It's excellent for this kind of stuff that might require fragmentation. What language are you using?

Share this post


Link to post
Share on other sites
UDP
65,535 bytes, 16 bits for the length.

UDP drops packets remember. If you send a packet that large and it doesn't get there you have to send the whole thing again. Look into reliable UDP and fragment your packets by the MTU. (like 1400 bytes or something).

Winsock isn't a language. I'll assume C++. Look at enet. It's a library.

Share this post


Link to post
Share on other sites
If you support filtering, it might help to structure your host listing as a subscription. Every once in a while, the server sends matching host records to the clients, rather than dumping them all upon subscription.

For example, you could have the hosting games send their stats every 5 seconds or so. When a packet comes in, the stats are filtered against the request for each listening client, and if matching, put on a queue for that client. About once a second, the queue for each client is put into a UDP packet and sent out. This way, hosted games automatically don't get put on client lists when stopped.

Meanwhile, a listening client should send its filter criteria every 5 seconds or so. When the server receives a message with filter criteria from a user, it creates a record of that client, and starts collecting matching server entries. If a client hasn't sent a packet in 15 seconds, that client is assumed to have stoped listening, and the record is deleted.

Doing it this way requires the client to be able to deal with asynchronous updates to the list of games, and also to be able to time out hosted games it hasn't heard of for a while (say for 15 seconds). However, the system is scalable and robust, because it is almost entirely reactive, and will automatically recover from dropped packets whenever the next update for a given host comes around.

The worst case for this system is a player who connects and requests no filtering and then stays connected for a long time without choosing a game. To solve that, require some kind of filtering (say, "game type" is always required), and then time out player connections. If a player has been looking for games for 5 minutes and not selected anything, put a note in the record for that IP/port, and don't forward any more packets, requiring the player to re-connect to get new data. Just don't implement auto-reconnect on the client side :-)

Share this post


Link to post
Share on other sites

This topic is 3460 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this