1 reply to this topic

[Angus Hollands]

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,

[papalazaru]

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.