top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

protocol design using C

0 votes

I am working on a system where I need to create a protocol to help communicate data back and forth. Im curious how you guys have tackled this in the past:
My protocol packet looks something like this:

enum class Command
 Authorize, //used to authorize a user
 Version, //used to get the version of the client.
 VersionR //used as the rversion reply.
 class Packet
 Command cmd;
 int flag;
 int length;
 P* payload;;

Now for all of the data, the P is the payload. So for example:

 class Authorization
 const char* name;
 const char* password;

The length of the payload can be retrieved and set as the length in the packet class. Is this something how people have implemented them in the past?

posted Jun 24, 2013 by anonymous

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button

2 Answers

+1 vote
Best answer

Basically, you are doing data serialization and unserialization when you do this sort of thing. Since you are doing C+, you can pretty easily write a serialization base class that you then derive from for your
classes that need serialization (virtual keyword). Then you pass the base class to Packet - it calls the virtual function in the base class that ends up calling your implementation.

I also recommend, if possible, using JSON for cross-platform sanity purposes (e.g. sending a float value). The only reasons to not use JSON are extensive binary data transfers and tons of small data objects. If you have to do either of those, then a binary serialization data format might be better. JSON parsers and generators exist for C and C+ (e.g. wxJSON if you use wxWidgets). Parsing tons of JSON might not be efficient either though - performance could suffer depending on what it is being used for. Pauls recommendation of the Google protocol buffers might be better.

One other tip: Make sure your system allows you to stream packets of data. Doing the whole "send data packet, receive data packet, send next packet, receive next packet..." thing is really old-school. You should
be able to send 10 packets and receive responses to those packets whenever because that plays nicer with TCP/IP. Use an incremental counter to track the packet number so you can match the response to the original message and get it to the right destination. If you dont care about performance and will always deliver packet responses in the same order they were sent in, the back and forth thing works fine enough.

answer Jun 25, 2013 by anonymous
0 votes

In the past, normally structs for each type of packet with a common set of initial members (one of which indicates the type of packet,) and a union of all the packets to make a generic packet.

Going forward, itll be Googles protocol buffers:

answer Jun 24, 2013 by anonymous
Similar Questions
+1 vote

Several messages are exchanged between UE and network nodes (eNodeB and MME) during attach procedure. I want to know in which all stages timers are used to guard various sub procedures of LTE attach procedure.