Is there a design pattern for this?

[me]

Hi there

I'm writing a messaging interface that takes a stream of binary data
from a socket, interprets it according to a message specification (field
names/lengths etc), and then acts upon the message.

My original design was to read from the socket until i got a code that
indicates the start of a message, then read MESSAGE_LENGTH bytes, then
pass it to another class for interpretation and actioning, thus getting
a nice seperation between the network interface and the actual data.

The problem is that some fields in the message have Field Extension
bits. In short, this means that if the LSB of the field is 1, then there
are extra bytes inserted in the message immediately afterwards.

So my problem is how do I interpret the message on the fly (in order to
read the correct number of bytes), while still maintaining seperation
between reading of the message bytes and their interpretation?

Cheers

pjw

 

[Jacques Labuschagne]

Hi there

I'm writing a messaging interface that takes a stream of binary data
from a socket, interprets it according to a message specification (field
names/lengths etc), and then acts upon the message.

My original design was to read from the socket until i got a code that
indicates the start of a message, then read MESSAGE_LENGTH bytes, then
pass it to another class for interpretation and actioning, thus getting
a nice seperation between the network interface and the actual data.

The problem is that some fields in the message have Field Extension
bits. In short, this means that if the LSB of the field is 1, then there
are extra bytes inserted in the message immediately afterwards.

So my problem is how do I interpret the message on the fly (in order to
read the correct number of bytes), while still maintaining seperation
between reading of the message bytes and their interpretation?

Cheers

pjw

Well, you could make the protocol sane.
This is exactly why most protocols use a tag-length-value approach. That
way you get a nice seperation between the transport layer, which only
needs to be able to find the outer-most length value and the application
layer, which knows about the individual fields carried by the message.

So, in short: every message should carry a fixed header which contains
the number of octets to follow in the body.

If you're not in control of the protocol, then you have my sympathies.

HTH,
Jacques.

 

[me]

Well, you could make the protocol sane.
This is exactly why most protocols use a tag-length-value approach. That
way you get a nice seperation between the transport layer, which only
needs to be able to find the outer-most length value and the application
layer, which knows about the individual fields carried by the message.

So, in short: every message should carry a fixed header which contains
the number of octets to follow in the body.

If you're not in control of the protocol, then you have my sympathies.

HTH,
Jacques.

Indeed. Unfortunately I cant change it.....

One idea I had would be to take data from the socket one byte at a time,
and pass it to the interpretor. The interpretor would then pass back
some kind of indication as to how big the next 'chunk' should be.

I'm somewhat resigned to that fact that its probably going to be
messy...especially as the interpretor and socket handler are in seperate
threads....

cheers

 

[Jesper Madsen]

I am just wondering about your design decision, having Interpreter and
Socket in 2 different threads.. I think I would introduce a package manager
that recieved a full package from the Socket, and passed it to the
Interpreter..
If the Interpreter needs to deal with transmission issues( gathering
packets, and checking they seem sane) and interprete the data, it will have
to many responsibilities (for my code anyway..)...

Jesper