Message Framing Question

[twhalen08]

Hello,

I am planning on using a byte buffer class to read values in and out of a byte array. The first thing i'm thinking of reading in would be a long to identify the message "type" so to speak.

Do you think this package is the best package to be doing this with? I believe what I am trying to do is essentially my own message framing scheme. I think going with Watson would include its own message framing scheme.

Caveman would be full control, but SuperSimpleTCP somewhere in the middle.

[jchristn]

Hi @twhalen08 moving this to a discussion, but I feel it's a really, really important one.

The pro of using WatsonTcp is that you don't have to build your own framing layer. The con is that if you need 1) non-WatsonTcp client support, or 2) support in some other language, you're rebuilding that framing layer. It's not that hard, but it's work.

The pro of building your own framing layer on SuperSimpleTcp is that you get exactly what you want. The con is that things can go wrong, very quickly actually. For instance, this library will attempt to read from the underlying socket using a fixed-size buffer. The number of bytes returned can differ if a) less data is delivered, b) network issues prevent delivery of all of the delivered data, or c) some other circumstance. B) in particular is problematic because your framing header may span multiple reads. So now, you have to concatenate data received events into a common buffer and parse once it reaches a certain size (greater than the size of your framing header). And, you have to maintain what is header and what is data. Personally, I would not use this library to build my own framing on top of, I'd use CavemanTcp.

The pro of building with CavemanTcp is quite clear: you can specify that your framing header is some number of bytes, and read until you get exactly that many bytes. Or, you can specify that your framing header is some variable number of bytes, but is always separated from the actual data by a specific set of characters, and in that case, you can read until you receive the delimiter.

Hope this helps!

[dreamparkvr]

Thanks a lot for the clarification that helps immensely.
I guess the only question I have left for you (at the moment) is, what is the best way to handle listening to each client for new data? My best guess (probably a naïve one) is to spin up a thread for each connected client to handle listening to the connection.

Again thanks for pointing me the right way. Much appreciated.

[jchristn]

Hi @dreamparkvr I'm happy to. The model you describe is what SuperSimpleTcp and WatsonTcp do. They spin up a background task with a DataReceiver method that continually listens. CavemanTcp also uses a background task, but lacks a discrete DataReceiver method (you as the consumer specify when to read).