Jump to content

  • Log In with Google      Sign In   
  • Create Account

Packets that contain multiple different types of data.


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
1 reply to this topic

#1 Angus Hollands   Members   -  Reputation: 722

Like
0Likes
Like

Posted 19 July 2012 - 09:54 AM

Hey everyone!
I am creating a base networking model for my game in Python.
Originally, I started using rencode to serialise native data structures like lists, dicts and tuples. |
This was good, but used lots of bandwidth (Far more than it needed to.)
I then switched to construct which was a "Pretty wrapper" over the Python struct module. This was as good; useable but also offered optimal packaging. However, the problem was that this method was too slow due to the various steps between calling the packing function and actually "packing".
So, I'm looking now at using the struct module manually, and offering the best mix between packing and speed.
However, I had a little thought; Most people recommend batching network packets into network ticks. That's fine, so here is a question about how to acheive it;

I would like to keep a model which is easily modifiable. Thus, It can't include too much hard coding, so here's my ideas.
  • Define a "Network event" as a series of bytes, with a header (~unsigned char 1 byte), event_size (~unsigned char 1 byte (size in bytes)) and contents.
  • This header is always read by the packet reader. It then looks up the event from some data structure, which returns two things.
  • It returns the base structure of the event - (e.g int, bool, short..), and the function to invoke with that data.
  • It reads the value of the packet, and gets the first header. It reads the packet from the header to the end of the first "event" defined by the event_size char). It then invokes an action with that data (before reading it) (excluding header).
  • It then reads the next byte knowing it's the next header, and continues the trend.
Is this a good / viable concept? It's a little trickier than in C++ as you have far less influence on what a packet actually is; you receive a byte stream of the packet contents, and the address it is received from,

Sponsor:

#2 0BZEN   Crossbones+   -  Reputation: 2025

Like
0Likes
Like

Posted 19 July 2012 - 01:14 PM

I suppose. There is no magic to it. Messages / events are aggregated into binary packets, and on the other end, you parse those messages / events back, forwarding them to the right message / event handler. Then move to the next message in the packet. How you do it is really up to you.

At the end of every network ticks, or when a packet is full (i.e. the next event that you try to add to a packet wont fit), you 'flush' the packet and start a new one.

It gets a bit more complicated when your messages / data structures are bigger than a packet MTU, then the packets need to be re-combined at the other end. Usually, your packet will have a header containing a sequence number, maybe a bitfield of flags, and if it is fragmented, a fragment index of some kind.

That's with UDP of course. With TCP, you don't even worry about message fragmentation at least on the transmitter side. Only on the receiver, you need to make sure the event / message you are trying to parse is complete before sending it to the handler.

Edited by papalazaru, 19 July 2012 - 01:18 PM.

Everything is better with Metal.





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS