Proposal to replace RPClib with ZeroMQ

Currently communication to and from the simulator happens using the rpc protocol. The reason for this is that AirSim uses it and this project was forked from AirSim. I believe ZeroMQ is a better fit. Therefore I propose to replace RPC with ZeroMQ. Note that msgpack encoding stays unchanged when moving to ZeroMQ.

The main problem with RPC is that it is a request-reply protocol. This results in clients having to poll to stay up-to-day with the available data. For sensordata this results in delays:

An rpc example: a lidar running at 20hz will capture a point cloud every 0.05 second. This pointcloud is stored in memory within the simulator. A client (the ros bridge) requests the latest pointcloud from the simulator at 20hz. There is no way to sync this timer with the simulator timer. When the client requests the pointcloud, the pointcloud is already outdated up to 0.049999 second. This latency could be minimized by requesting sensordata more frequently, but having all sensors execute request at, let's say, 500hz is doomed to introduce new performance issues.

A publish/subscribe architecture would better fit what we are trying to do. The simulator would be able to push sensor data to clients as soon as it becomes available. Clients get lower latency sensordata.

Only few mature, open-source, cross-language, broker-free, networking libraries supporting both publish-subscribe and request-reply exist. From my googling I have come to believe ZeroMQ is the best option as it has the great documentation, seems easiest to use and performs great.

Before I start with a prototype to test the feasibility of ZeroMQ as a replacement for RPClib, I would like to hear if this plan in general makes sense to you. I would love to hear questions, remarks and concerns!

Iniziare esaminando la comunicazione attuale del simulatore tramite rpclib, in particolare il flusso dei dati dei sensori tra il simulatore e client come il ROS bridge. Valutare se ZeroMQ possa supportare i pattern publish-subscribe e request-reply richiesti mantenendo la codifica msgpack. Il lavoro sarebbe completato quando saranno concordati un risultato di fattibilità e l’ambito della migrazione, ma l’issue non indica file o test.