response for TraCI context subscription contains invalid command length

[kschrab]

When adding a context subscription via TraCI for a vehicle (0x84) to retrieve surrounding vehicles (0xa4) , the response message contains an invalid command length.

Command:
00 00 00 2a 26 84 40 1c 00 00 00 00 00 00 40 8f 40 00 00 00 00 00 00 00 00 05 76 65 68 5f 31 a4 40 69 00 00 00 00 00 00 01 40

Response
00 00 00 20 07 84 00 00 00 00 00 00 00 00 00 14 94 00 00 00 05 76 65 68 5f 31 a4 01 00 00 00 00

Expected Response:

00 00 00 19 07 84 00 00 00 00 00 11 94 00 00 00 05 76 65 68 5f 31 a4 01 00 00 00 00

Detailed description found in the following images. The command length in the actual response (2nd picture) starts with a byte value of 0, implying an extended length field. the subsequent integer then contains a value of 20. However, the actual length of the whole command, including the length field of 5 bytes, is 21 bytes long in total. Therefore, I would expect that 21 would be the actual content of the length field.

The expected response would use the normal length field using one byte only, as the command length is shorter than 255 bytes:

SUMO-version: 1.12.0

operating system: Windows 10

[behrisch]

It does not affect the python client which simply ignores the length of the return string but it is definitely a bug. Thanks for tracking this one down!

[behrisch]

Just for the record: None of our clients checks the length of the (inner) return message and consequently none of our clients will be able to handle multiple messages in one batch although the TraCI protocol allows it.

[kschrab]

Something still seems to be wrong:

I now get an invalid response when sending a normal vehicle subscription (0xd4):

Receiving a response with a length of 156 bytes:
00 00 00 9c 07 d4 00 00 00 00 00 95 e4 ...

with
00 00 00 9c = 156 bytes length (this is correct)
07
d4 -> vehicle subscription
00 00 00 00 00 -> status code = "ok"
95 = 149 bytes command length (! this is wrong, should be 145!)

I proposed a solution in 78d59dd#r66731320

[behrisch]

You are right. But I think it may be better to revert to always sending the extended length. This way all clients relying on the old behavior (e.g. Traas) will still work. What do you think?

[kschrab]

Sure, I see no problem there.