Context for client API?

[infn-ke]

How can a client use two different transport channels? Looks like there is no context in the generated code, instead the global variable g_client is used to retrieve the transport object.

[github-actions]

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

[MichalPrincNXP]

Hello @infn-ke , yes, correct, it is not possible to use two different transports, this use case is not supported. @Hadatko , is there any way how to achieve this? I am afraid not when using current implementation.

[Hadatko]

Hi. I think we have only complicated way to achieve this.
User can create g_client1 g_client2... and before rpc call change g_client (g_client=g_client1, g_client=g_client2).
Or have two transport layers and before rpc call assigned correct one (g_client.setTransport(transport1), g_client.setTransport(transport2)).

Not sure if it is good idea when arbitrator is used.

[infn-ke]

Looks like same limitation also applies to the server side? Server only supports one transport layer, but can handle multiple services? Is that a valid statement? No simple way for a server to support two transport layers?

[Hadatko]

Hi @infn-ke , Actually server is different case. You can have several server instances each with different transport layer. You can run every server in different thread. Or using poll function you can all controll in one thread.

[infn-ke]

Is there a roadmap to fix the client context issue? Multi-client support from one process is quite common use case.

[Hadatko]

I would do it in two step. First support multiple clients in C++ similar way as we do in Python. Then we can discuss if we need support C workround. Bellow is described what would change in source files.