Network Game Programming

From Visual Basic to GNU C, this is the place to talk programming.

Moderators: SecretSquirrel, just brew it!

Network Game Programming

Postposted on Wed May 25, 2011 4:18 pm

I've been asked to rewrite some networking code for a friend's project (it's called revert -- github link).

Right now it's set up to just serialize anything that's serializable and the deserialize on the other end. This is kind of annoying if you're only sending 1 float and it's 1+ KB in size.

Is there any resources out there on working with this kind of information efficiently? We're willing to use other libraries or re-invent the wheel here :P
Image
Nitrodist
Grand Gerbil Poohbah
 
Posts: 3280
Joined: Wed Jul 19, 2006 1:51 am
Location: Minnesota

Re: Network Game Programming

Postposted on Wed May 25, 2011 4:22 pm

Winsocks2 + binary structure?
Core 2 Duo E6300, MSI P45 NEO-F, Club 3D GTX 260, 4Gb DDR2-800Mhz, Audigy X-Fi Fatal1ty Champ1on ed., 0.5Tb+1Tb Seagate Barracuda 7200.12, 630W AXP, Samsung SyncMaster BX2450, ViewSonic VP171b
Madman
Minister of Gerbil Affairs
 
Posts: 2317
Joined: Tue Apr 01, 2003 4:55 am
Location: Latvia

Re: Network Game Programming

Postposted on Wed May 25, 2011 9:25 pm

Nitrodist wrote:I've been asked to rewrite some networking code for a friend's project (it's called revert -- github link).

Right now it's set up to just serialize anything that's serializable and the deserialize on the other end. This is kind of annoying if you're only sending 1 float and it's 1+ KB in size.

Is there any resources out there on working with this kind of information efficiently? We're willing to use other libraries or re-invent the wheel here :P


Yep, the arcane and horribly documented RPC XDR libraries contain what you need. They will pack and unpack binary data. They should also be relatively cross platform, if that matters. There is no reason a float should ever be 1KB+ in size. 20-30 bytes at the most and that's if you convert it to a string for transmission. Even if you stuck it inside an XML structure as a string representing a float, it shouldn't be more than 100bytes or so.

The key, and Madman made reference to it in a way, is that RPC expects structured data and both ends have to understand the structure.

--SS
SecretSquirrel
Gerbil Jedi
Gold subscriber
 
 
Posts: 1686
Joined: Tue Jan 01, 2002 7:00 pm
Location: The Colony, TX (Dallas suburb)

Re: Network Game Programming

Postposted on Wed May 25, 2011 10:14 pm

Nitrodist wrote:Right now it's set up to just serialize anything that's serializable and the deserialize on the other end. This is kind of annoying if you're only sending 1 float and it's 1+ KB in size.

Is there any resources out there on working with this kind of information efficiently? We're willing to use other libraries or re-invent the wheel here :P

I like Protocol Buffers. After suffering through using sunrpcgen for years to generate XDR stubs, protobuf's clean generated interfaces are a breath of fresh air (and, before anyone calls me a shill, I used and liked it long before I was paid to use it). It's not perfect, but it's better than any other cross-language serialization tool I've used.
bitvector
Grand Gerbil Poohbah
 
Posts: 3234
Joined: Wed Jun 22, 2005 4:39 pm
Location: Mountain View, CA

Re: Network Game Programming

Postposted on Thu May 26, 2011 2:39 pm

bitvector wrote:
Nitrodist wrote:Right now it's set up to just serialize anything that's serializable and the deserialize on the other end. This is kind of annoying if you're only sending 1 float and it's 1+ KB in size.

Is there any resources out there on working with this kind of information efficiently? We're willing to use other libraries or re-invent the wheel here :P

I like Protocol Buffers. After suffering through using sunrpcgen for years to generate XDR stubs, protobuf's clean generated interfaces are a breath of fresh air (and, before anyone calls me a shill, I used and liked it long before I was paid to use it). It's not perfect, but it's better than any other cross-language serialization tool I've used.


How are you paid to use it? Thanks for the link -- looks very useful.
Image
Nitrodist
Grand Gerbil Poohbah
 
Posts: 3280
Joined: Wed Jul 19, 2006 1:51 am
Location: Minnesota

Re: Network Game Programming

Postposted on Thu May 26, 2011 3:13 pm

You probably know this already and were just exaggerating, but you'll never get any efficiency sending around single floats. The packet overhead alone will kill you. Sometimes elegance and simplicity has to yield to performance, and that may mean bunching up a lot of unrelated stuff in your payload to keep your wire efficiency high.
UberGerbil
Gerbil Khan
 
Posts: 9971
Joined: Thu Jun 19, 2003 3:11 pm

Re: Network Game Programming

Postposted on Thu May 26, 2011 3:33 pm

Just a few quick thoughts...

- I agree with UberGerbil, sending packets that small is extremely inefficient. Once you factor in the overhead of passing the packet through the network stack at both ends, you may find that cutting the size of the packet from 1K to (say) 20 bytes buys you squat in terms of overall efficiency. Generally you'll want to aggregate small data items together to reduce the per-packet overhead penalty.

- If there are parts of the protocol which require low latency, and other parts which require efficient operation to move large amounts of data, you will need to make intelligent decisions about when to aggregate things and when to flush them out to the network interface immediately.

- For applications which are extremely latency and/or time sensitive, but which can tolerate a certain amount of packet loss, you may wish to consider using UDP instead of TCP.
(this space intentionally left blank)
just brew it!
Administrator
Gold subscriber
 
 
Posts: 37495
Joined: Tue Aug 20, 2002 10:51 pm
Location: Somewhere, having a beer

Re: Network Game Programming

Postposted on Thu May 26, 2011 4:50 pm

If this is for a game that requires timing of any sort then size efficiency isn't what you should be concerned about.

What you need to use is pipelining. Divide gametime into even timeslices and pack everything together for each. Then send the packs immediately without waiting for the previous pack to arrive at the destination (up to a preset number).


If the timing needs to be really tight (e.g., fighting games) then a form of asynchronous timing will have be implemented. Your input, the other side's inputs, what you see on the screen and what the other side sees on their screen are more loosely coupled. Take a look at GGPO for an implementation.
ChronoReverse
Gerbil Elite
 
Posts: 736
Joined: Wed Dec 12, 2007 4:20 pm

Re: Network Game Programming

Postposted on Thu May 26, 2011 11:28 pm

just brew it! wrote:Generally you'll want to aggregate small data items together to reduce the per-packet overhead penalty.

- If there are parts of the protocol which require low latency, and other parts which require efficient operation to move large amounts of data, you will need to make intelligent decisions about when to aggregate things and when to flush them out to the network interface immediately.

- For applications which are extremely latency and/or time sensitive, but which can tolerate a certain amount of packet loss, you may wish to consider using UDP instead of TCP.
So, an interesting point about your suggestion of aggregating small data items together and flushing them out: on most systems, the TCP implementation is often using something like Nagle's algorithm to do that underneath your application anyway. The socket option TCP_NODELAY is there to disable this for interactive applications. Of course, even with Nagle's algorithm disabled TCP is still not idea for low-latency games, but one could use both, keeping a TCP connection for when bulk reliable transfer is necessary and using UDP for continuous latency-critical signaling updates.

Nitrodist wrote:How are you paid to use it? Thanks for the link -- looks very useful.
Well, I'm not really paid to use it specifically, but we use it extensively at Google.
bitvector
Grand Gerbil Poohbah
 
Posts: 3234
Joined: Wed Jun 22, 2005 4:39 pm
Location: Mountain View, CA

Re: Network Game Programming

Postposted on Fri May 27, 2011 7:08 am

UberGerbil wrote:You probably know this already and were just exaggerating, but you'll never get any efficiency sending around single floats. The packet overhead alone will kill you. Sometimes elegance and simplicity has to yield to performance, and that may mean bunching up a lot of unrelated stuff in your payload to keep your wire efficiency high.


Specifically, the effective time to send 1 byte is the same as a 1000. As others have said, the overhead for the network stack far outweighs the actual transmission time. Keep your packets as close to a multiple of 1365 bytes for best efficiency. This of course assumes standard ethernet MTU of 1500 bytes and TCP packets.

--SS
SecretSquirrel
Gerbil Jedi
Gold subscriber
 
 
Posts: 1686
Joined: Tue Jan 01, 2002 7:00 pm
Location: The Colony, TX (Dallas suburb)


Return to Developer's Den

Who is online

Users browsing this forum: Yahoo [Bot] and 1 guest