7 replies to this topic

[Farkon]

Hello,

Below is how my datas are packed :

[UDP HEADER][SEQ][ACKED_SEQ][TYPE][LENGTH][BITMASK][X][Y]
  28bytes    int    int     1byte  1byte    1byte   b  b

I'm trying to find how much players can fit in a 50kb/s upload connection.

header_size = 28 + 8
msg_size = 5
players = 15
netfps = 30

packet_size = header_size + players * msg_size
outgoing_size = packet_size * players
bandwidth_needed = outgoing_size * netfps
>> 49 950 for 15 players

First question, is my math ok ?

Also, i'm using 4bytes for my sequences, I could use 1 byte if i say that after 255 it goes back to 0. Of course it's problematic since i'm discarding too old packets based on that sequence but i could build something really ugly on top of it and maybe totally unsafe. Is that something which has already been done in those situations ? Are there some algorithms for it ? How stupid is that idea ?
I can almost answer the last question in my situation since reducing the header_size from 36 to 30 let me accept half a player more. I guess it could matter at larger players scale but not here.

Can i be more compact than what i'm doing ? I'm voluntary ignoring variable netfps, hidden players...
I could remove the length field since i know how much size my properties have, but that's all. With this and my weird new 2bytes msg header i'm now at 17 players. Knowing that it's not even true in real game experience since i'm having projectiles which counts as much as a player in a stress situation.

And by curiosity, how much bandwidth i could get for a dedicated server at ~40$/m ? (not VPS)

[Antheus]

Quote

And by curiosity, how much bandwidth i could get for a dedicated server at ~40$/m ? (not VPS)

Unlimited, but without QoS guarantees. Also subject to fine print.

[BeerNutts]

Farkon, on 17 February 2012 - 08:22 AM, said:

Hello,

Below is how my datas are packed :

[UDP HEADER][SEQ][ACKED_SEQ][TYPE][LENGTH][BITMASK][X][Y]
  28bytes	int	int	 1byte  1byte	1byte   b  b

I'm trying to find how much players can fit in a 50kb/s upload connection.

header_size = 28 + 8
msg_size = 5
players = 15
netfps = 30

packet_size = header_size + players * msg_size
outgoing_size = packet_size * players
bandwidth_needed = outgoing_size * netfps
>> 49 950 for 15 players

First question, is my math ok ?

Also, i'm using 4bytes for my sequences, I could use 1 byte if i say that after 255 it goes back to 0. Of course it's problematic since i'm discarding too old packets based on that sequence but i could build something really ugly on top of it and maybe totally unsafe. Is that something which has already been done in those situations ? Are there some algorithms for it ? How stupid is that idea ?
I can almost answer the last question in my situation since reducing the header_size from 36 to 30 let me accept half a player more. I guess it could matter at larger players scale but not here.

Can i be more compact than what i'm doing ? I'm voluntary ignoring variable netfps, hidden players...
I could remove the length field since i know how much size my properties have, but that's all. With this and my weird new 2bytes msg header i'm now at 17 players. Knowing that it's not even true in real game experience since i'm having projectiles which counts as much as a player in a stress situation.

And by curiosity, how much bandwidth i could get for a dedicated server at ~40$/m ? (not VPS)

You're asking the wrong question. it's not how many players you can fit within a certain rate, it's how many players per second can you fit? And, that answer depends on how often you update.

A typical UDP packet's MTU is 1518 (or 1520 I forgot). If you don't want to break up your packets, then you need to keep that in mind. So, you have 1518-36 = 1482/5 = 296 (rounded down) players can fit into one UDP packet.

How often you send that packet is what will determine your datat rate.

[Farkon]

BeerNutts, on 17 February 2012 - 10:27 AM, said:

You're asking the wrong question. it's not how many players you can fit within a certain rate, it's how many players per second can you fit? And, that answer depends on how often you update.

I don't get how this is different, or maybe i wasn't clear enough but my little piece of code shows that i wanted to know how many players the server can handle knowing the net loop rate and message size.

I didn't think about fragmentation though.

[hplus0603]

First, you absolutely should truncate sequence numbers to one byte each. If you send 10 packets per second, that means you have to drop all packets for 12 seconds before that will become ambiguous. The algorithm to sync those two bytes is "if unsigned_byte(A - B) > 128, then B is ahead of A, else A is ahead of B" -- that needs to cast the subtraction to unsigned char, just like the inputs A and B are.

Second, you probably want to run-length encode "old" data in your packets, so that you know what to do if a packet or two is dropped. This will make the data size of the packet variable, but will make it much more robust for an input-synchronous networking system.

Third, I'm not sure your math checks out. You need to send data about all users, to all users. That's 46 kiloBYTES per second. A 50 kbps connection only does 50 kiloBITS per second.

Fourth, if you know that the update is exactly "one update of three bytes for each player in order," then each of those updates don't need type/size -- you can squish it to 3 bytes per player, and perhaps one type/length code at the front of that array.

Fifth, $50/month will buy you a small dedicated server with 10 Mbps uplink and 2 TB of bandwidth. Trying to cram more than 2 TB of bandwidth through a 10 Mbps uplink in a month is actually pretty hard, so you wouldn't really have to worry about overages. You'd probably run out of CPU or RAM before you ran out of bandwidth.

[wodinoneeye]

If you can stack multiple sub messages into each UDP packet you could lower the overhead (they could share the seq & seq_ack data and obviosuly the header). Positions of multiple other players goes back the other way so that would be a candidate at least. (Processing overhead on Network routines probably isnt that significant unless its on the server and you are driving alot of packets).

I'm not up on what are effective max sizes for packets over Internet you want to send (MTU 1492 but many older routers and such break them into 512 ) but you have some room to send at least a few multiples. I suppose you could even have an adaptive scheme to adjust the max size on a per connection basis.

[hplus0603]

wodinoneeye, on 17 February 2012 - 05:15 PM, said:

If you can stack multiple sub messages into each UDP packet you could lower the overhead

He's already doing that.

Quote

I'm not up on what are effective max sizes for packets over Internet you want to send (MTU 1492 but many older routers and such break them into 512 )

Each UDP packet (there is one to each of 15 players, 30 times a second) is < 100 bytes in the proposal.

[Farkon]

hplus0603, on 17 February 2012 - 01:13 PM, said:

First, you absolutely should truncate sequence numbers to one byte each. If you send 10 packets per second, that means you have to drop all packets for 12 seconds before that will become ambiguous. The algorithm to sync those two bytes is "if unsigned_byte(A - B) > 128, then B is ahead of A, else A is ahead of B" -- that needs to cast the subtraction to unsigned char, just like the inputs A and B are.

Ah, that's actually very elegant, thanks.

Quote

Second, you probably want to run-length encode "old" data in your packets, so that you know what to do if a packet or two is dropped. This will make the data size of the packet variable, but will make it much more robust for an input-synchronous networking system.

I'm not sure i understand this part, or at least the way you do it. But i'm implementing a q3style system where i'm making delta compression against the last acked state so if i'm having a dropped packet it will get the next packet and use it instead of waiting for a RTT.

Quote

Third, I'm not sure your math checks out. You need to send data about all users, to all users. That's 46 kiloBYTES per second. A 50 kbps connection only does 50 kiloBITS per second.

I meant 50kbytes/s sorry.

Quote

Fourth, if you know that the update is exactly "one update of three bytes for each player in order," then each of those updates don't need type/size -- you can squish it to 3 bytes per player, and perhaps one type/length code at the front of that array.

Ah indeed !

Quote

Fifth, $50/month will buy you a small dedicated server with 10 Mbps uplink and 2 TB of bandwidth. Trying to cram more than 2 TB of bandwidth through a 10 Mbps uplink in a month is actually pretty hard, so you wouldn't really have to worry about overages. You'd probably run out of CPU or RAM before you ran out of bandwidth.

Great to know that, thanks