Jump to content
  • Advertisement
Sign in to follow this  
KuJi

the 'perfect' network protocol.

This topic is 3869 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Recently i've been trying to develop a network protocol but I always seem to find myself stuck. I'd think of an idea for one, set it all up, it works for small packets but say I wanted to transfer over files or something -- I'd be beaten by the stream :(. I just can't seem to figure out a good enough protocol for TCP. I've tried about 2-3 different methods including recv 4 bytes (an integer of the length of the packet, then receiving the actual length). Receiving a large amount of data and breaking it off at the '\r\n' characters. With still no success, does anyone have a good idea or reference to a well-working protocol?

Share this post


Link to post
Share on other sites
Advertisement
How about UDP? A packet is a packet, so if it arrives then you know how big it is. It's much faster than TCP and it's easier to plan your bandwidth budget for your multiplayer games (because you know how much data is coming / going, without resends for lost packets).

Obstacles are that packets may not arrive in order, and in fact they may not arrive at all. In all honesty these are not huge obstacles, they just need a bit of careful planning. Ie reliable packets are resent until we receive an acknowledgment, and sequenced packets are given a sequence number so older packets can be discarded when they arrive.

Hope this helps, and good luck!

Share this post


Link to post
Share on other sites
Quote:
With still no success, does anyone have a good idea or reference to a well-working protocol?


What exactly was the problem?

Share this post


Link to post
Share on other sites
Quote:
Original post by TheGilb
How about UDP? A packet is a packet, so if it arrives then you know how big it is. It's much faster than TCP and it's easier to plan your bandwidth budget for your multiplayer games (because you know how much data is coming / going, without resends for lost packets).

Obstacles are that packets may not arrive in order, and in fact they may not arrive at all. In all honesty these are not huge obstacles, they just need a bit of careful planning. Ie reliable packets are resent until we receive an acknowledgment, and sequenced packets are given a sequence number so older packets can be discarded when they arrive.

Hope this helps, and good luck!


I plan to incorporate UDP for less-secure things like players positions.

Quote:
Original post by Antheus
Quote:
With still no success, does anyone have a good idea or reference to a well-working protocol?


What exactly was the problem?


Big packets will end up getting mixed up with other packets.

Share this post


Link to post
Share on other sites
That's not a protocol problem, that's an implementation problem.

Take a look at Etwork. It implements limited-size messages on top of TCP, and works even if you happen to only get part of the header at a time.

In general, to get good latency for important packets, if you're sending something bigger, you should send that in many small chunks, and re-assemble them on the other side. This is useful even if you're using TCP rather than UDP, because it lets you interleave your big transmission with other messages.

Share this post


Link to post
Share on other sites
Quote:
Original post by hplus0603
That's not a protocol problem, that's an implementation problem.

Take a look at Etwork. It implements limited-size messages on top of TCP, and works even if you happen to only get part of the header at a time.

In general, to get good latency for important packets, if you're sending something bigger, you should send that in many small chunks, and re-assemble them on the other side. This is useful even if you're using TCP rather than UDP, because it lets you interleave your big transmission with other messages.


I do that by sending in bytes of 8192.

Share this post


Link to post
Share on other sites
Quote:
Original post by hplus0603
So what do you do when you only need to send 14 bytes in a message?


int x = 14;
min(x, 8192);

Share this post


Link to post
Share on other sites
Right, but you're saying you have problems with the stream mixing the packets up. That means you're not properly sending a length followed by the data, or you are not properly buffering the data on the receiving side.

Share this post


Link to post
Share on other sites
Quote:
Original post by KuJi

Big packets will end up getting mixed up with other packets.


Rather than playing "guess the problem" game, got any code to show? It tends to be a bit more productive, and leads to quicker problem solving.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!