Sign in to follow this  
Farkon

Data size & circular sequences

Recommended Posts

Farkon    192
Hello,

Below is how my datas are packed :

[CODE]


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

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

[CODE]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[/CODE]

[b]First question, is my math ok ?[/b]

Also, [b]i'm using 4bytes for my sequences, I could use 1 byte[/b] 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 ? [b]How stupid is that idea ?[/b]
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.

[b]Can i be more compact than what i'm doing ?[/b] 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, [b]how much bandwidth i could get for a dedicated server at ~40$/m ?[/b] (not VPS)

Share this post


Link to post
Share on other sites
Antheus    2409
[quote]And by curiosity, [b]how much bandwidth i could get for a dedicated server at ~40$/m ?[/b] (not VPS)[/quote]

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

Share this post


Link to post
Share on other sites
BeerNutts    4400
[quote name='Farkon' timestamp='1329488529' post='4913913']
Hello,

Below is how my datas are packed :

[CODE]


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

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

[CODE]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[/CODE]

[b]First question, is my math ok ?[/b]

Also, [b]i'm using 4bytes for my sequences, I could use 1 byte[/b] 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 ? [b]How stupid is that idea ?[/b]
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.

[b]Can i be more compact than what i'm doing ?[/b] 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, [b]how much bandwidth i could get for a dedicated server at ~40$/m ?[/b] (not VPS)
[/quote]

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.

Share this post


Link to post
Share on other sites
Farkon    192
[quote name='BeerNutts' timestamp='1329496075' post='4913949']
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.
[/quote]

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.

Share this post


Link to post
Share on other sites
hplus0603    11347
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.

Share this post


Link to post
Share on other sites
wodinoneeye    1689
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.

Share this post


Link to post
Share on other sites
hplus0603    11347
[quote name='wodinoneeye' timestamp='1329520535' post='4914037']
If you can stack multiple sub messages into each UDP packet you could lower the overhead[/quote]

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 )
[/quote]

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

Share this post


Link to post
Share on other sites
Farkon    192
[quote name='hplus0603' timestamp='1329506009' post='4913984']
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.[/quote]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.[/quote]
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.[/quote]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.[/quote]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.
[/quote]Great to know that, thanks [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img]

Share this post


Link to post
Share on other sites

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