Hello again Well I''ve got a nice little client/server setup running. Right now I have just a single client running and sending packets roughly 100 times a second. They are all getting transferred flawlessly. Now, I''m not checking for the occassional lost one or anything but every time I check, the sequence numbers are all correctly lined up. All the client is doing is making a new packet and sending it to the server. The server is simply receiving all packets and printout their contents. Now I''m wondering about just how many packets per second can I expect a given client to be sending? I know this is a very subjective question and will certainly depend on the game but anyone got some rough estimates? Things that will have to be transmitted are character placement, state, stats, etc and all of these go across at regular intervals. These will be the number of packets per client I''ll need to handle MINIMUM multiplied by the number of clients on the server. Obviously, nothing will answer these questions better than plain old testing but I am curious as to how many can be expected in general? TIA Webby

Probably no more than 10 per second, depending on how fast the player can type. This is for a MUD.

---

How appropriate. You fight like a cow.

Do a little math:

Are you targeting a modem? Those can do at most 53,200 bits per second. That means about 6 kilobytes per second; 4 if you want to allow for non-optimal connections.

Now, there''s about 30-50 bytes of header per packet (less for UDP, more for TCP, possibly with a bit shaven off by van Jacobsen header compression. There might be size added by PPP or PPPoE or PPTP or similar encapsulations.

Allright, so 10 packets per second, 40 bytes header overhead per packet, and 4 kilobytes per second, means that each packet shouldn''t be bigger than 360 bytes or so. That''s going TO the client. Most modems these days give slower performance upstream (to server) than downstream (which is the numbers I gave here).

You could also turn this around: how big packets do you need to send? Add header overhead. Divide your available bandwidth by this value -- that''s how many per second you can send.

Also consider the bandwidth on the server end. If you have 100 clients sending 10 packets a second, then that is 10,000 packets all trying to get across the server''s one connection.

These numbers seem pretty high to me

Webby, you''re writing a MMORPG, aren''t you? I am as well, and my numbers aren''t anwhere near each client sending 100 packets a second, or even 10 packets a second.

Granted, my game isn''t done yet (by a long shot ), but the basics are there, and my experience is showing the average client sending any of my various packets once every second or so, with spikes of four or five a second.

The majority of my packets are input packets, and these are limited by player keystrokes or mouse clicks. Chat is sent on a per message basis (not per character) so even the fastest typer generally won''t send a packet more than once every few seconds. Movement can be a little quicker, especially turning since it autorepeats 20 times a second (only applies if you''re doing a 3D MMORPG, I suppose), which is where I was getting most of my spiking with sends.

I suppose clients could click on a UI button very quickly and cause packet send spiking, but I haven''t seen this to be the case so far (perhaps my testers are more patient than the normal players? ).

One area where I expect a lot of packet transfer to a particular client is at login, when a lot of character and world data must be passed from server to client at once as they start up. I haven''t coded most of that in yet. But even so, I don''t expect a whole ton of packet requests per second (I have a one second delay on autorepeating packet requests, so there should be several info requests for different things (world data, character data, inventory, etc), then a one second delay for responses, followed by repeats for those (if any) that didn''t come in).

I would guess that if your server can handle 5 packets per second per client, you have plenty of room. Just based on what I''ve seen so far in my very imcomplete game. YMMV

-Ron

quote:

---

Original post by andy_fish
Also consider the bandwidth on the server end. If you have 100 clients sending 10 packets a second, then that is 10,000 packets all trying to get across the server's one connection.

---

usually real time games dont have masses of players anyways, but some do

100*10 = 1000 packets/second

[edited by - drekkar on August 30, 2003 3:25:21 AM]

Thanks guys
Like I alluded to in my question, I''m not looking for the all powerful number. More of a "what are you doing" sort of thing. In the end, the number of packets my game can handle will depend on tons of things like
1) Servers banwidth
2) Servers computing speed and code speed
3) Target client connection restraints
3) How many packets do I actually "REQUIRE" for the game to function properly at a minimum
4) Many more.

So the answers I got here were great. I think what I was mostly looking for was some comparisons compared to my current tests.

The client and server network is going to be very similar with the client''s functionality being a very stripped-down version of the servers so the amount of communuication the server can handle will also go down to the client (+- factors for their computing power and internet connection).

I think my networking code is running very nicely now. I''ve had it being tested over the internet with a few of my friends. They are all local (within 20 miles) so the results can only be interpreted so much but so far things are looking nice.

The next thing I am going to look at is packet compression, compounding and some other code optimizations. Want to squeak out as much speed here as possible as in these kinds of games, the network code can quickly become the source of lag for everyone.

Thanks for the replies,
Webby

With sufficently robust timming protocols and the proper control dynamics and extrapolation algorithims you can get away with an on demand type data transmission protocol. This will greatly reduce your bandwidth usage.

For example, given a sufficently advance timming protocol which can sync your clocks to within 10 ms of each other, your temporal resolution is about 1/100 of sec. Using this as the basis for your movement extrapolation algorithms, you can have some guarantee of the conistentcy of players postion over time.

Youll need to implement a robust control protocol, where redundant user events are culled on the client side to prevent flooding the server, and proprogating redundant state changes to the other clients. The protocol also needs to be sensentive to the latency of the user. Timeout, acks, resends all need to be aware of the users latency, and implement more or less extraplolation and redeundacy as needed.

Also having an error metric within the game will help you determine when you need to throttle state resync packets to the client. For instnace knowing when players positions are divering from the servers, or when the important state bits are out of sync with the servers.

With these systems in place you may only need to send 1 or 2 packets a second on average.

-ddn