Sign in to follow this  
rogerdv

designing my protocol, essential information

Recommended Posts

Im in the process of creating the protocol for my udp based client-server communication. Im figuring out what info should go in all packets. Right now, I know I have to include a packet counter to ensure correct order of processing. All packets from client side includes a player unique id to speed up player search in server side. What else could be included?

Share this post


Link to post
Share on other sites
The Forum FAQ has some links.

Including a player ID isn't all that useful, because an attacker could put in a fake ID, so you'd have to compare against a known authentication token, or the remote IP address, anyway. Doing a hash-lookup on source IP address+port isn't noticeably slower than a direct array index anyway (two cache misses vs one); I'd just save the network bytes and not send that ID.

Depending on what your protocol needs to do, I'd look at the design of TCP (there are good books on the subject), or the implementation of something like Enet for inspiration.

Share this post


Link to post
Share on other sites
Here's my packet layout; dunno if it's any good, but it works for me...

1 byte packet flags; currently just Encrypted
[per message:
1 byte message flags Reliable|Sequenced|Ordered|LargePayload|Fragmented|System
1 byte sequence channel
2 byte sequence number
1 or 2 byte payload length
[payload]
]

Acks (positive and negative) are sent as a "regular" message.

Share this post


Link to post
Share on other sites
You don't need to use a sequence number per message in a packet; you just need a sequence number per packet, because you know what you put into each packet. It's slightly trickier to implement, but it saves on the overhead per message.

Share this post


Link to post
Share on other sites
Aw shucks, that sounds like it might work; back to the drawing board ;-) The only downside I can think of, except extra bookkeeping, is that ordered packets would still need a sequence number per message...

Share this post


Link to post
Share on other sites
I think its sufficient; sequence numbers are wrapped which means you'll only run into problems if a packet is more than 65535 packets late; and that's per channel (255 channels)

Share this post


Link to post
Share on other sites
Is a packet going to be even the least bit relevant if it's 100 packets late? I would think that using a single-byte sequence number would be sufficient for most game protocols. You'd detect that something's amiss long before you wrap around.

Share this post


Link to post
Share on other sites
While we're on the topic...

How big is a decent payload? I don't want to crap packets down their throat, but i'll be pretty frequently sending them out, to give this a twitch feeling.

What do you guys use?

Share this post


Link to post
Share on other sites
I think the "twitch feeling" aspect is more important than the "payload size" aspect. If you need 20 packets per second for the right twitch feeling, then you need to send packets every 50 milliseconds, even if you only have 20 bytes of data. That would actually be a good target for data rate for an 8-player multiplayer game for modems: 400 bytes per player per second means 8 players == 3200 bytes per second plus packet overhead.

Share this post


Link to post
Share on other sites
Quote:
Original post by hplus0603
Is a packet going to be even the least bit relevant if it's 100 packets late? I would think that using a single-byte sequence number would be sufficient for most game protocols. You'd detect that something's amiss long before you wrap around.


True, i've been thinking of a compromise; using 5 bits for channels (32 channels) and 11 bits for sequence number (2048 unique numbers)

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