Switch from TraCIAPI to libsumo and/or libtraci

[riebl]

The TraCIAPI has been marked as deprecated by SUMO from version 1.9.0 on. We will have to switch to the newer libsumo and/or libtraci in the foreseeable future because we cannot expect any feature updates for TraCIAPI anymore.

Some users seem to have demand for features missing in the venerable TraCIAPI, e.g. #212.

[Enough7]

#212 is a dead link, what was the content of the issue?

[riebl]

I cannot recall the details anymore. One of the limitations has been the lack of support for SUMO's GUI back then. This might have changed meanwhile.

[AshFungor]

Hey, @riebl!

I think it's about time I should pick this task. To begin with, what is the difference between libsumo and libtraci? From the pages you provided, it seems like libtraci is just better libsumo. Can you clarify? :)

Also, I'll research the differences we'll need to implement and decompose this issue into sub-issues. I anticipate quite a lot of work :)

[riebl]

With libsumo, the SUMO traffic simulation runs in the same process space, i.e. as part of the OMNeT++ simulation process. With libtraci, the traffic simulation is a separate process and Artery (the OMNeT++ process) exchanges data with this process via the TraCI protocol.
The API of both, libsumo and libtraci is almost identical so you can exchange them rather easily. Please refer to https://sumo.dlr.de/docs/Libsumo.html for some limitations of libsumo. I am not sure if Artery would be hit by the limitation regarding the subscription mechanism.

I have used libsumo already in another project where it worked quite nicely.

[AshFungor]

Hey, @riebl!

Sorry for the delay on this issue. I've started the migration and some things about it compel me to discuss a few technical details with you. Firstly, I've looked up libsumo limitations and the one that hits the most is inability for libsumo consumers to connect to already running SUMO instance. This means that ConnectLauncher will not be available anymore with it - which is sad since I know people out there using it.

Secondly, I have some design questions:

• I noticed that you try to separate code as much as possible: I've seen headers with a single struct inside, for example. Do you find this approach preferable, still? Most software I've worked with ties things up usually :)
• You used to wrap compat layer for TraciAPI inside traci namespace. May I know why? :) I think that placing stuff like that could cause naming collisions in user code.

[riebl]

Hi @AshFungor,

maybe we can exploit the fact that libsumo::Simulation and libtraci::Simulation are distinct types but with equal API. That would allow the user to pick the best fitting approach at runtime. I am not yet sure how this could be realised without duplicating code, though.

I usually create separate headers for "main" structs so you can easily derive the name of the header file where you have to look for it. Auxiliary structs tightly bound to a another struct usually go to the header of its main struct. I admit this approach is no longer as useful with more powerful IDEs but it is not harmful either.

The whole traci namespace is pretty much standalone, i.e. you could use it without the other Artery modules. I have once considered to provide this OMNeT++ TraCI integration as a separate repository, but this never happened. Why do you think that traci may cause naming collisions? SUMO itself uses libtraci and libsumo namespaces exclusively.

[AshFungor]

maybe we can exploit the fact that libsumo::Simulation and libtraci::Simulation are distinct types but with equal API.

I'm kinda confused why they did that, because the API is literally the same but defined in different namespaces which makes macros the only possible solution to avoid copy-paste. I'm thinking this:

libsumo defines:

#ifdef LIBTRACI
#define LIBSUMO_NAMESPACE libtraci
#else
#define LIBSUMO_NAMESPACE libsumo
#endif

we may apply namespace alias on macro:

namespace sumo_compat = LIBSUMO_NAMESPACE;

And then use context switches on LIBTRACI if we need different logic for libsumo/libtraci. At runtime, as you mentioned, we just load different shared libraries depending on what user needs.

Why do you think that traci may cause naming collisions? SUMO itself uses libtraci and libsumo namespaces exclusively.

I know, it's just that I'm used to follow "the same namespace for the project" paradigm. Like, when I see traci::foo() I'm automatically thinking it's something to do with SUMO. On the contrary, something like artery::traci::foo() implies that a component belongs to Artery. Maybe it's just me though :)) Oh and naming collisions - I mean SUMO developers may utilize that namespace again someday. You never know :))

Auxiliary structs tightly bound to a another struct usually go to the header of its main struct. I admit this approach is no longer as useful with more powerful IDEs but it is not harmful either.

Personally, I use clangd shortkey Ctrl + Left mouse button and it brings up class/struct/function definition. And definitions usually go to *Defs header, like SUMO does in TraCIDefs.h. I'll stick with this approach for now and then we may refactor stuff later - should not be much of the problem.

[riebl]

Though the API is identical because of the LIBSUMO_NAMESPACE trickery, no common base class exists which would support switching between libsumo and libtraci at runtime. I suggest to stick with libtraci for now which is more similar to the existing approach. We could support libsumo as a CMake option for advanced users where we also switch between both variants by flipping macro definitions. What do you think?

AFAIK, clangd is younger than Artery ;-)

[AshFungor]

Hey, @riebl!

I wish to write some unit tests for new SUMO bridge. Do you know if anyone is writing comprehensive unit tests for individual modules on popular C++ testing frameworks? I know that opp_test exists, but it seems extremely inconvenient to use, since:

• it integrates building test into a test file which means we have to handle it somehow with CMake
• it integrates writing code into a test file, which is a turn-off for me since it means little to no code quality at all

I know both INET and Omnet++ use opp_test. Veins seems a bit abandoned and uses Makefiles for buildsystem. Unfortunately, there are no more projects I know about. I trust you have much wider view of Omnet++ consumers than me :)

Alternately, I may dive into simulation kernel and write some dummy components implementing Omnet++ interfaces. I keep in mind that we also have to switch to newer Omnet++ version sooner or later, so hopefully porting this code won't be a problem.

[riebl]

I suppose the INET framework reflects the state-of-the-art in testing OMNeT++ modules.