2 Replies - 455 Views - Last Post: 11 November 2017 - 12:33 PM Rate Topic: -----

#1 jjl  Icon User is offline

  • Engineer
  • member icon

Reputation: 1269
  • View blog
  • Posts: 4,997
  • Joined: 09-June 09

A robust protocol

Posted 09 November 2017 - 02:33 PM

Hey guys, I write a good amount of networking software, and I was think lately about protocol robustness. I typically deal with TCP sockets and I use the "typical" message header for all my messages.

struct MessageHeader {
    uint16_t type;
    uint32_t bytes;
};



I usually put in checks to look for bogus length fields and valid types, but what about the scenario when a client sends a message with a "valid" length, but doesn't actually send a payload which the header says it is? I usually multithread the clients, so hanging the server is not an issue, but the protocol will become out of sync for the client.

Are there any methods you guys use to synchronize a protocol under these circumstances?

I though about using a synchronization start/stop word (maybe 4 bytes of a known value) to resync the protocol, but it seems messy.

[start sync][MessageHeader][Payload][end sync]

This post has been edited by jjl: 09 November 2017 - 05:00 PM


Is This A Good Question/Topic? 0
  • +

Replies To: A robust protocol

#2 Skydiver  Icon User is offline

  • Code herder
  • member icon

Reputation: 5889
  • View blog
  • Posts: 20,095
  • Joined: 05-May 12

Re: A robust protocol

Posted 10 November 2017 - 06:46 AM

So this is not a matter of the network being unreliable and losing/corrupting data, but rather the client being unreliable and sending bad data?

The cynic in me says GIGO, but typically is not an acceptable answer nowadays. Most of the MPEG and other digital streaming protocols have a "pulse" or "heartbeat" signal that is sent within the stream data and that is how things get back in sync again. But in your case, if the client couldn't be relied on to send good data, how can you rely on them to send the re-synchronization signal appropriately?
Was This Post Helpful? 0
  • +
  • -

#3 jjl  Icon User is offline

  • Engineer
  • member icon

Reputation: 1269
  • View blog
  • Posts: 4,997
  • Joined: 09-June 09

Re: A robust protocol

Posted 11 November 2017 - 12:33 PM

You are correct, it is really for the purpose of syncronization and also detecting bad data from the client. I think I am going to frame the data with sync words, this will allow me to detect bad data, which also allows me to detect bad sync words.

I basically just want a way to be able to detect bad data and be able to send an error back to the client, rather than going out of sync quietly

A heartbeat cant really be used since, like you said, I cant assume that the data is valid. But if first look for a sync word, then read the message, then look for an end sync. I can easily get back iin sync when 1 of the conditions fail.

This post has been edited by jjl: 11 November 2017 - 12:36 PM

Was This Post Helpful? 0
  • +
  • -

Page 1 of 1