TransportInterface and NetworkContext switching. Model implement

Libraries
1

Hi all,

The problem lies in the implementation of the Transport model, for different networks and connections, proposed by FreeRTOS.

The project I am working on, is based on a device (ESP32 240Mhz, DualCore) from which I am going to use both its Wi-Fi interface and the GSM (physical layer),
on which I use a tcpip stack to simultaneously connect to a server, and to another ESP32 device.
I open up to 2 connections to the other ESP32 device (one for control and the other for transfer) and any of the 2 can act as a client or as a server,
so they can initiate the connection or accept the incoming one.

I hope I have described it clearly enough.

The problems start when the different task’s try to change the network context “TransportInterface_t”.
If I don’t use semaphores, there are clashes in the pointers to the Send, Recv, etc etc functions and if I use semaphores to change context, it becomes really slow, since in each context change all the pointers have to be copied to the main functions. for a semi-active state, it is not a problem, but when there is a load or several connections transmitting, the speed drops drastically, much much more than if I do not use the “TransportModel”.

The questions is…

Is there any way to use the TransportInterface proposed by FreeRTOS without having to make the switch for each message that comes or goes to another context?

I have seen and reviewed the different examples of MQTT using the TransportInterface, but my case is much more complex and I don’t know if it is planned or if there is something I haven’t fully understood.

Any help or explanation is appreciated.
Thank you all.

2

Are you looking for 2 different implementation of transport interface in the same application? OR 2 connections using the same transport interface implementation? If later, it would depend of your implementation of transport interface is thread safe. In this example, you should be able to create 2 network contexts by calling TLS_FreeRTOS_Connect twice and use them independently.

If I have not understood your use case correctly, would you please share some code to make it clear?

3

Thanks, for reply.

Yes, and Yes.

2 diferent implementations for 2 diferent interfaces, and 2 same implementations for 2 connections on the same interface. :slight_smile:

I have tested the sugested sample, but you are right. I become problems with sharing the threads. First i need to make it thread safe, and later i will see …

Any way, thanks for reply.
To be continued …