Future Multiple Client/Transport Support

[ramlco]

Hello,
I was just curious if there are any plans for eRPC to support multiple clients and/or transports in the future.

Looking at previous posts (#52), I see that a workaround is suggested but it is not clear whether it will cause other problems.

Thank you in advance for the help!

[github-actions]

Hi eRPC user. Thank you for your interest and welcome. We hope you will enjoy this framework well.

[MichalPrincNXP]

Hello @ramlco , supporting multiple clients and providing such examples is on the todo list but due to other work priorities this is not going to be done soon, unfortunately.

[ftab]

what about a router system which will be able to handle more than one client and more than one transport? The concept is similar in nature to a message router I used to work on which could transfer messages between devices in the system whether they were running on the same processor, directly connected to another, or connected between different transports.

Let's start with this arrangement:

MCU A <---UART---> MCU B

One transport is easy enough, and bidirectional client/server is taken care of by the transport arbitrator which looks at the message type (invocation / one way: pass it to the server; otherwise, process it in the client)

MCU A has WiFi, Bluetooth, CAN. MCU B has USB, another CAN. One or the other might have an audio DAC attached. Some of the IO pins that need to be twiddled might be on the other end. They use eRPC to pass information back and forth to each other so the application code doesn't need to care which core it's running on

Would be great to use the same idea to provide RPC for a desktop or mobile app client over those other transports so you have one single source of truth: the IDL. Imagine some Python script running on the PC to assist in automated testing, debugging, or development

the tricky part becomes how do you get the WiFi client able to call something on MCU B?

Well, if you expand the arbitrator approach a little bit, it could handle such a situation where the thing that receives it is not directly able to service it, but it knows who can

I think an eRPC "server hello" message could be created to say what is its server name and what are the service IDs it serves. Maybe there is a client hello, as well.

The router would have a list of registered transports, a list of servers, and the service IDs those servers have.

After the startup "hello", MCU A has the following list:
Transports:

• UART (ID 1)
  • Server 1: self
    • Service: Net (service ID 1)
    • Service: CAN A (service ID 2)
  • Server 2: MCU B
    • Service: USB (service ID 3)
    • Service: Audio (service ID 4)
    • Service: CAN B (service ID 5)
• TCP (ID 2)
  • Server 1...
• Bluetooth (ID 3)
  • Server 1...
• CAN (ID 4)
  • Server 1...
• etc.

A client connects over TCP and requests something from the USB drive. MCU A knows that service 3 is available on server 2, over UART, so it forwards the message to that transport. (Perhaps there is a transport ID and client ID added to the header so that when the response comes back, the router knows which TCP client to send it back to)

This assumes each service can only be served by one device in the system, and you don't mind all services being available to all clients

Indirectly routing may be easy enough as well. Let each server post the services it has available across all its transports. Then if a transport is running over CAN on MCU B, and an external device connects with a server that has a "diagnostic" service ID 6, then MCU B posts back to MCU A that it not only handles 3, 4, and 5, but now 6 as well. MCU B then has this routing list:

• UART (ID 1)
  • Server 1: self
    • Service: USB (service ID 3)
    • Service: Audio (service ID 4)
    • Service: CAN B (service ID 5)
  • Server 2: MCU A
    • Service: Net (service ID 1)
    • Service: CAN A (service ID 2)
• CAN (ID 4)
  • Server 1: self
  • Server 3: diagnostic
    • Service: diagnostic (service ID 6)
• etc

And MCU A now has this routing list:

• UART (ID 1)
  • Server 1: self
    • Service: Net (service ID 1)
    • Service: CAN A (service ID 2)
  • Server 2: MCU B
    • Service: USB (service ID 3)
    • Service: Audio (service ID 4)
    • Service: CAN B (service ID 5)
    • Service: diagnostic (service ID 6)
• TCP (ID 2)
  • Server 1...
• etc.

Could get a little foggy as to how the multiple bounces works, so maybe at first it only supports one degree of Kevin Bacon

Hope at least some of that was clear enough. I love me some pipe dreams.