Own C++ network protocol: How to define unique binary telegram values - c++

Question

I want to exchange data over TCP/IP with C++ by writing my own small binary protocol. My idea was to implement the protocol by defining values in form of the following bytes:
BEGIN
LENGTH
FUNCTIONCODE
[data bytes] (optional)
CRC
END
How can I define a binary value for "BEGIN" that is unique allowing the receiver to recognize the beginning of a new telegram? E.g. if I do that:
static const int BEGIN = 0x41;
and the optional data bytes randomly include also the 0x41 value, this might be a problem for the receiver. Or am I wrong? If not, how may I define a unique BEGIN and END value?

Answer 1

I usually write something like this for simple C++ networking. (But I wrote this code from scratch this time and haven't tested it at all!)
class Packet : public std::string {
public:
struct __attibute__((__packed__)) Header {
static const int BEGIN = 0x41;
uint32_t begin;
uint16_t length;
uint16_t funcode;
void init(uint16_t len) { begin = BEGIN; length = len; }
bool verify() { return (BEGIN == begin); }
char *buffer() { return reinterpret_cast<char *>(this); }
};
class __attibute__((__packed__)) Footer {
uint32_t crc;
char term;
char newline;
void init() { term = ';'; newline = '\n'; }
bool verify() { return (';' == term && '\n' == newline); }
char *buffer() { return reinterpret_cast<char *>(this); }
};
public:
void init(size_t n = 0) {
resize(sizeof(Header) + n + sizeof(Footer));
Header * const h = header();
h->init(n);
Footer * const f = footer();
f->init();
}
// these two are valid only after init()
Header *header() { return reinterpret_cast<Header*>(&(*this)[0]); }
Footer *footer() { return reinterpret_cast<Footer*>(&(*this)[size() - sizeof(Footer)]); }
template <typename T>
T *buffer() { return reinterpret_cast<T *>(&(*this)[sizeof(Header)]); }
void extend(size_t n) { resize(size() + n); }
};
int sendMessage(int funcode) {
Packet p;
switch (funcode) {
case TIME: {
timeval tv;
gettimeofday(&tv, NULL);
p.init(sizeof tv);
Packet::Header * const h = p.header();
h->funcode = funcode;
timeval * const dst = p.buffer<timeval>();
*dst = tv;
} break;
case PID: {
const pid_t pid = getpid();
p.init(sizeof pid);
Packet::Header * const h = p.header();
h->funcode = funcode;
pid_t * const dst = p.buffer<pid_t>();
*dst = pid;
} break;
...
}
Packet::Footer * const f = p.footer();
f->crc = ...;
const ssize_t nSent = send(sock, p.data(), p.size(), 0);
...
}
Packet receiveMessage() {
Packet ret;
ret.init();
Packet::Header * const h = ret.header();
ssize_t nRecv = recv(sock, h->buffer(), sizeof *h, 0);
...
if ( ! h->verify()) ...
p.extend(h->length);
nRecv = recv(sock, p.buffer<char>(), h->length, 0);
switch (h->funcode) {
case TIME: {
timeval tv = *p->buffer<timeval>();
tm theTm;
localtime_r(&tv.tv_sec, &theTm);
char buf[128];
strftime(buf, sizeof buf, "%x %X", &tv);
cout << "Server time == " << buf << endl;
} break;
case PID: {
const pid_t pid = *p.buffer<pid_t>();
cout << "Server PID == " << pid << endl;
} break;
...
}
Packet::Footer * const f = ret.footer();
nRecv = recv(sock, f->buffer(), sizeof *f, 0);
if ( ! f->verify() || f->crc != ...) ...
return ret; // inefficient data copy, only for a sample code
}
I recommend you to define your BEGIN code as something like 0x48454c4f which can be read as ASCII "HELO" rather than a random int like 0x41. And I added two extra bytes ';' and '\n'to the footer; you will find them useful when you dump packet capture of your protocol to the console. Remember, you can always use sed, perl, python or whatever (but not grep; it won't accept arbitrary hex search strings) to analyse arbitrary binary data including your packet dump. If you design your protocol well, your debugging will be much easier. (First of all, you should consider using ASCII protocol rather than binary one.)

Answer 2

Frequently a protocol definition goes like this:
FUNCTIONCODE
LENGTH
DATA
CRC
and there's no need to fish for "BEGIN". Reading proceeds by reading FUNCTIONCODE and LENGTH using a fixed length, and then the data + CRC, according to LENGTH, and then, again...
However, if you think that the additional "BEGIN" marker helps you, select "BEGIN" as a value that's not a FUNCTIONCODE, and then you have
BEGIN
FUNCTIONCODE
LENGTH
DATA
CRC
And for every byte after BEGIN equal to BEGIN send BEGIN twice. But, in this case, reading is much more complicated...