[dss-developer] tcp message format for vDC-API

[Lukas Zeller]

Hi Arne,

as the author of all vdc side vDC-API code (see p44vdc and vdcd projects at github.com/plan44) I can confirm that the documentation you quote is correct.
There's nothing more than two bytes of length, followed 1:1 by the bytes as produced by vdcapi__message__pack() which is a protobuf-C generated routine.

You can see this happen in lines 1164..1180 of https://github.com/plan44/p44vdc/blob/master/vdc_common/pbufvdcapi.cpp
Similarily, the receiving (a bit more complicated because of buffering etc.) is also in the same file, the essentials starting at line 1117.

The code at the vdSM end is not the same source, but certainly does the same thing - because the two do communicate this way as I write and switch on my light, for which I have build the vdcd from those very sources myself ;-)

I guess there must be some tiny byte-eating or -producing dragons between what you see in your dumps and what actually is sent via TCP ;-)

Greetings,
Lukas



> On 8 Jan 2021, at 12:31, Familie Speck <haus at speck-familie.de> wrote:
> 
> Hi,
> 
> As I am trying to use the vDC-API via an on-the-fly protobuf compiler I need to have some more information about the tcp message format.
> The API documentation simply says that “The TCP stream consists of a 2-byte header containing the length of the following message(16 bits, in network byte order, maximum accepted length is 16384 bytes) followed by the protocol buffer message” Nevertheless I figured out that e.g. the real protobuf message for the “hello” message coming from the dss starts not before the 11th byte (for the ping message it is the 8th byte). The first two bytes obviously really give the overall message length. The last single byte before the protobuf message seems to give the length of the protobuf message following. – Now I need to know how the part in between is created to decompose and create working messages.
> Can anyone explain in detail how the messages are structured, please?
> 
> 
> 
> Here are two examples of what I found out until now for the 48byte hello messages and the 43byte Ping messages I was able to derive and decode the protobuf part from:
> 
> 
> 
> Hello:
> 
> 0:0         fix for hello message - first of two bytes for length of the following message
> 
> 1:46      fix for hello message – second of two bytes for length of the following message
> 
> 2:8         seems to be fix for “hello” messages
> 
> 3:2         seems to be fix for “hello” messages
> 
> 4:16      seems to be fix for “hello” messages
> 
> 5:X         seems to be variable – nevertheless, it seems as if this value is counting up per distributed message to same vDC Host (with every message I receive this value is counting up
> 
> 6:X         no regularity detected mostly 6 or 7
> 
> 7:162    seems to be fix for “hello” message
> 
> 8:X         no regularity detected mostly 6 or 7 – (same value as byte 6???)
> 
> 9:38      fix for hello message – seems to hold length information on following protobuf part
> 
> 10-47:   protobuf message that can be successfully decoded
> 
> (interesting that I get an api-version of “3” reported from dss whereas documentation is still saying that it is valid for api-version 2….)
> 
> 
> 
> Ping:
> 
> 0:0
> 
> 1:41      see above
> 
> 2:8         seems to be fix for “Ping” messages
> 
> 3:8         seems to be fix for “Ping” messages
> 
> 4:202    seems to be fix for “Ping” messages
> 
> 5:X         seems to be variable looking at hello message – nevertheless for Ping Messages I only received 6 as a value
> 
> 6:36      fix for ping message – seems to hold length information on following protobuf part
> 
> 7-42:     protobuf message that can be successfully decoded
> 
> 
> 
> Would be really good to get some Information on how I can derive the information which proto message type the message includes, at which byte the proto part starts – and of course how I will have to compose the messages I am sending from the vDC Host to the vdSMon DSS….
> 
> 
> 
> Thanks in advance for giving me some insights here….!
> 
> 
> 
> BR,
> 
> 
> 
> Arne Speck
> 
> _______________________________________________
> dss-developer mailing list
> dss-developer at forum.digitalstrom.org
> http://forum.digitalstrom.org/cgi-bin/mailman/listinfo/dss-developer

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL: <http://forum.digitalstrom.org/pipermail/dss-developer/attachments/20210110/a553c50f/attachment.pgp>