Hello Michael,
thank you for looking into this! You were right, there was a mistake in
the code, here:
https://github.com/CodingConnected/CodingConnected.Traci/blob/b6a8c99c5d1ed2a9dc614f01041f5a2c9ac0c4b1/CodingConnected.TraCI.NET/Helpers/TraCIDataConverter.cs#L311
where the case of messages longer than 255 should be handled, but the
array boundary check looked at the wrong variable. This indeed fixed the
problem.
Wrapping the C++ might be tricky, given that C++ is not managed as is
C#. An obvious choice would be to use Traas, but I prefer not having an
extra layer in between. Also writing the implementation taught me a lot
about the protocol, which was fun (though implementing all various
commands now is a bit tedious...).
Thanks again!
Greets, Menno
Op 19-1-2018 om 19:05 schreef Michael Behrisch:
Hi Menno,
my knowledge of C# is not that advanced but it may be that you are not
reading the response length correctly. The TraCI protocol sends a zero
as first byte to indicate that the following four bytes contain the
length as integer for messages which are longer than 255 bytes. My
impression of
https://github.com/CodingConnected/CodingConnected.Traci/blob/master/CodingConnected.TraCI.NET/Helpers/TraCIDataConverter.cs
was that you are not handling that case.
BTW, we are happy to see the list of TraCI client implementations grow
but wouldn't it be easier to use the existing C++ client and maybe wrap
it a little? This would save you from implementing those gory TraCI details.
Best regards,
Michael
Am 19.01.2018 um 10:37 schrieb Menno van der Woude:
Hello,
currently I am expanding the API coverage of my TraCI implementation in
C# (https://github.com/CodingConnected/CodingConnected.Traci).
On testing my implementation for, for example, data retrieval commands
related to lanes (0xa3), I am finding that:
- get ID count (0x01) returns a number, like 68
- however, get ID list (0x00) returns nothing; TraCI acknowledges the
request, reports it succeeded (0x00) in the acknowledgement, but there
is no further content in the data received via tcp
I am using SUMO 0.32 for this.
The same happens with junctions, edges and vehicle types. Interestingly,
with detectors (type 1, 2, 3) and traffic lights, retrieving the ID list
works just fine. The implementation for these commands is identical
between all types, using a generic method.
Any ideas?
Greets, Menno
_______________________________________________
sumo-dev mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/sumo-dev
_______________________________________________
sumo-dev mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/sumo-dev
