jeremyczhen / fdbus

FDBus - Fast Distributed Bus
https://blog.csdn.net/jeremy_cz/article/details/89060291
161 stars 85 forks source link

[Non-Issue] FDBus performance & features discussion #20

Open rockcafe3in1 opened 3 years ago

rockcafe3in1 commented 3 years ago

Okay, first I need declaim that the following content might not an issue, but a few interesting questions in my mind, which might be same ones as most of us in this field might interested in. Thanks for your contribution of IPC implementation in open source world, it is great job, and we could learn a lot from your achievements. Meanwhile, we would thank you for sharing your project in Github.

The FDBus were implemented based on Client-Server messaging model as you recorded in your blog, we are interested in the background or trade-off when you make decision on choosing Client-Server Model. As we know in In-Vehicle industry, there is trends in which consists of time-critical information delivery, large quantities of information exchange, unreliable delivery mechanism, all these scenario could happen in the near future Autonomous Car industry. Therefore, I will appreciated if you could share more information regardless evaluation details/results of FDBus solution with real-time delivery performance, resources overhead, etc. (I know this might not be good way to ask for directly, especially in open source world). You can just ignore it

Anyway, thanks for your contribution! We learn a lot from it.

jeremyczhen commented 3 years ago

Thank you for interested in this project. CS model is very nature if the underlying IPC is based on socket. Binder which doesn't depends on socket also adopt CS model. This doesn't means CS is the best choise. Notification center like MQTT is another model, which can also find its usage in specific cases. Thereby recently support of notification center is also added to FDBus: https://github.com/jeremyczhen/fdbus/wiki/Event-Cache-and-Notification-Center.

In vehicle, data can be roughly divided into 3 classes: 1. should be passed without error/dropping but tolerance to delay; 2. cyclically sent with low latence but can be dropped; 3. sensitive to delay or jitter. TCP targets class1; UDP targets class 2; AVB targets class 3. At this moment FDBus only supports TCP. But UDP will be supported soon and test is on going at branch UDP-for-broadcast-and-send.

The reason why no benchmark for FDBus is that performance of FDBus is not bottomneck until now. It is very small in footprint, self-contained and no dependence on other open-source libraries. Unlike D-Bus, there is no central hub to route messages. It is distributed and equivalent to point-to-point connection with socket. Anyway I'll come up with a benchmark at QC8155 or Raspberry Pi board for your reference.