Object-oriented networking

Question

I\'ve written a number of networking systems and have a good idea of how networking works. However I always end up having a packet receive function which is a giant switch stat

Answer 1

A more OO way to handle this is to build a state machine using the state pattern.

Handling incoming raw data is parsing where state machines provide an elegant solution (you will have to choose between elegant and performance)

You have a data buffer to process, each state has a handle buffer method that parses and processes his part of the buffer (if already possible) and sets the next state based on the content.

If you want to go for performance, you still can use a state machine, but leave out the OO part.

Answer 2

I would use Flatbuffers and/or Cap’n Proto code generators.

Answer 3

About the way to handle the packet type: for me the map is the best. However I'd use a plain array (or a vector) instead of a map. It would make access time constant if you enumerate your packet types sequentially from 0.

As to the class structure. There are libraries that already do this job: Available Game network protocol definition languages and code generation. E.g. Google's Protocol Buffer seems to be promising. It generates a storage class with getters, setters, serialization and deserialization routines for every message in the protocol description. The protocol description language looks more or less rich.

Answer 4

When you are doing OOP, you try to represent every thing as an object, right? So your protocol messages become objects too; you'll probably have a base class YourProtocolMessageBase which will encapsulate any message's behavior and from which you will inherit your polymorphically specialized messages. Then you just need a way to turn every message (i.e. every YourProtocolMessageBase instance) into a string of bytes, and a way to do reverse. Such methods are called serialization techniques; some metaprogramming-based implementations exist.

Quick example in Python:

from socket import *
sock = socket(AF_INET6, SOCK_STREAM)
sock.bind(("localhost", 1234))
rsock, addr = sock.accept()

Server blocks, fire up another instance for a client:

from socket import *
clientsock = socket(AF_INET6, SOCK_STREAM)
clientsock.connect(("localhost", 1234))

Now use Python's built-in serialization module, pickle; client:

import pickle
obj = {1: "test", 2: 138, 3: ("foo", "bar")}
clientsock.send(pickle.dumps(obj))

Server:

>>> import pickle
>>> r = pickle.loads(rsock.recv(1000))
>>> r
{1: 'test', 2: 138, 3: ('foo', 'bar')}

So, as you can see, I just sent over link-local a Python object. Isn't this OOP?

I think the only possible alternative to serializing is maintaining the bimap IDs ⇔ classes. This looks really inevitable.

Answer 5

A map of handler instances is pretty much the best way to handle it. Nothing inelegant about it.

Answer 6

You want to keep using the same packet network protocol, but translate that into an Object in programming, right ?

There are several protocols that allow you to treat data as programming objects, but it seems, you don't want to change the protocol, just the way its treated in your application.

Does the packets come with something like a "tag" or metadata or any "id" or "data type" that allows you to map to an specific object class ? If it does, you may create an array that stores the id. and the matching class, and generate an object.