0
votes

I would like to send messages structures throw the TCP/IP socket. I decided to use std::asio (or boost::asio) library. My decision is based on fact that boost asio is a multi platform and one of my client need to run on windows machines.

Please take a look at the messages structures.

#pragma once

#define SENSOR_LENGTH 5
#define OPERATOR_NAME_LENGTH 100


// extend it on demand
typedef enum msg_type_t {
    NO_MSG,
    INIT_MAMBA_REQ,
    INIT_MAMBA_RESP,
    INIT_TELESCOPE_REQ,
    INIT_TELESCOPE_RESP,
    START_EVENT_MAMBA_REQ,
    START_EVENT_MAMBA_RESP,
    START_EVENT_TIMEPIX_REQ,
    START_EVENT_TIMEPIX_RESP,
    STOP_EVENT_MAMBA_REQ,
    STOP_EVENT_MAMBA_RESP,
    STOP_EVENT_TIMEPIX_REQ,
    STOP_EVENT_TIMEPIX_RESP
} MSG_TYPE;

typedef struct msg_hdr_t {
    MSG_TYPE MsgType;
    long seqNum;
} __attribute__((packed))MSG_HDR;


typedef enum _runType
{
    CUSTOM=0,
    BIAS,
    ANGLE
} __attribute__((packed)) RunType;

typedef struct init_event_t{
    RunType runType;
    int dutRunNumber;
    int biasVoltage;
    int angle;
    int stageX;
    int stageY;
    double temperature;
    unsigned short sector;
    char sensorName[SENSOR_LENGTH];
    char operatorName[SENSOR_LENGTH];
}__attribute__((packed))InitEventReqStruct;


typedef struct init_event_rsp{
    int keplerRunNumber;
}__attribute__((packed))InitEventRespStruct;

typedef struct stop_event_req{
    bool isGood;
}__attribute__((packed))StopEventReqStruct;


typedef union msg_data_t {
    bool empty;
    InitEventReqStruct initEventReq;
    InitEventRespStruct initEventResp;
    StopEventReqStruct stopEventReq;
} __attribute__((packed))MSG_DATA;
2
And the question is.... ?WhozCraig
I forgot to add it. Of course the question is how can I do that?user1877600
I'm afraid it's going to take code. Once you attempt it, and perchance run into problems, this is a great place to bring the your code, intents, reproduction steps, etc, and have them examined for weeding out problems and proffering up fixes.WhozCraig
Use google protocol buffers. Creating your own encoding protocol is a waste of time.Richard Hodges
Different endianess? Different word size? Different OS? Different programming languages? Message extensibility required? Any "yes" will get you in trouble with homebrewn solutions. Answer the questions to get tailored help.stefan

2 Answers

1
votes

First, as yourself a question if C++ or boost::asio complexity is acceptable for the customer. The fact that you can do C++ (I do and I like) doesn't mean it is sane choice from business perspective. People knowing those complex technologies are hard to hire. Python, C#, Java or Ruby are more accessible.

Putting language considerations aside, you need to serialize your structure before sending it over the wire and deserialize it upon reception.

There are many ways to do it. You can convert those structures to XML or JSON, as the internet crowd does it. You can write your own, binary serializer-deserializer, trading poor maintainability for super-performance. Or you can use some generators to create ser-des boilerplate.

Check out protocol buffers: https://developers.google.com/protocol-buffers/

Take a look at Boost.Serialization: http://www.boost.org/doc/libs/1_60_0/libs/serialization/doc/index.html

I would probably take a look at XML/JSON first, before jumping into more complex solutions. JSON and XML are being used to send structured data over the wires all over the internet, between all imaginable technologies. Java, for example, can offer you fantastic libraries to deserialize JSON into Java classes without a single line of code.

Rethink your choice. Don't reinvent the wheel.

0
votes

I agree with the overall sentiment here that a serialization library is the way to go. They tend to address problems that may not occur to you until later (different endianness between platforms, message versioning, and so on). For binary serialization, any of the following are worth considering and have active communities behind them:

The one you pick will depend on your needs and preferences. Some have better support for message versioning, optional fields, and backwards compatibility. Some require you to run an IDL through a compiler that spits out generated classes, some just require you to add a little extra code to your own existing types. Supported data types may vary slightly.