packet overhead

Networking & Multiplayer
#1

Hi

Just did some testing of my current client, I added some debug into it to dump the number of bytes sent and received. The result was

Sent 16472 and received 166582 bytes of game data in 74 seconds, thats 0.21679688KBps and 2.1982422KBps

Then I ran IPTraf on the box hosting it

┌ TCP Connections (Source Host:Port) ────────── Packets ─── Bytes Flags Iface ┐ │┌85.211.203.76:3210 = 358 39511 DONE eth0 │ │└67.18.125.146:2000 = 500 264461 CLOSED eth0 │

That means the server (as in box, not SGS) sent 264461 bytes, but of that, only 166582 was game data, the rest was TCP packet headers and SGS overheads. Now I admit that most of my messages were only 72 bytes of game data, there is a minimum of 20 bytes of TCP header. My question is, how much does SGS add per messages?

Endolf

#2

Hm. The ansewr to this is “nothing”.

Now how much does the default transport protocol add? I dunno, but ill ask.

P.S. TCP headers are always multiples of 32, so its 32 bytes, not 20.

#3

Yea I already looked at that using a sniffer. And the anwnser is it depends on the type of message and the delivery mechanism you use (aka RELIABLE, ORDERED, etc)…

Messages sent on the channel seem to be sized rougly like this: UTF encoded length of channel name + length of data + senderSessionId length + 19 bytes. Some of those 19 bytes is header data and some seems to be delimeter data… Maybe shorts, ints, or longs describing the length of the data, sessionId, and channel name? I’m guessing on that but it seems to fit. Not sure exactly what the header stuff is but it varies based on the type of message being sent… Keeping in mind that it seems the protocol itself has messages it sends that are not based on anything you are sending. For example when you join a channel a message is sent to the client. Probably the message that triggers the joinedChannel event.

Data sent directly to the server and back seems to be a bit more efficient. It is roughly message.length + 7 bytes. I am guessing that is the length of the message bytes and maybe some basic header stuff? Something like that.

#4

Is this a bits/bytes mix up?

I though it’s multiples of 32 bits, minimum 5 words, maximum 15, thus it’s 20-60 bytes. It wouldn’t be the first time I was wrong though :slight_smile:

Useful info floersh, looks like an insentive to keep those channel names nice and short :slight_smile:

Endolf

#5

Dunno, I’ll double check. But my memory was 32 byte header on TCP/IP. Could be wrong.

Answer from the team btw is that client/server is very efficient. Channel messages are not in this version and they are aware it can use improvement.

Ultimately, though, if you don;t like what they’ve done, the community will be able to write pluggable transports to do it however works best for your applications.

#6

I’m thinking I need to figure out a way to bunch my messages up so I send more per packet, but at the moment, I send a position update ever 250ms or so on channels, and I don’t really want to start introducing any more latency on that if I can help it.

I can certainly live with it at the moment :slight_smile:

Endolf

#7

Btw your right. 20 bytes.

I wonder what my memory of 32 is… maybe it was indeed bit width shrug

#8

I’ve done some more digging on this, and we are both right :slight_smile:

TCP header is indeed 20 bytes (5 32 bit words). However, thats TCP, TCP/IP has an extra 3 32 bit words, for a total of 32 bytes :slight_smile:

TCP has no source/destination addresses, only ports, IP adds the addresses and some extra information.

See http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Header for details :slight_smile:

Endolf

#9

Maybe because 32 in decimal == 20 in hexadecimal ;D