|Re: [sumo-dev] TraCI ID_LIST command return nothing for lanes|
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#L311where 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 sumo-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/sumo-dev
Back to the top