I'm studying the LWIP QP example, where the TCP/IP is running on a dedicated AO. I'm thinking what is the best solution if I need to use other protocols that need to use the TCP/IP stack. For example, if I need to use Modbus on TCP/IP, or I need to connect to a cloud to download/publish some information, I need to call the TCP/IP stack APIs. I think I have two possibility:
Create an AO Network Manager to handle the TCP/IP stack. Create some events that can manage the requests to open/close a socket, send/receive data to/from a socket. In this case, I protect the access to the TCP/IP stack and the others AO that need to call a TCP/IP stack API, will post an event to the AO Network Manager.
Create an AO that manage multiple orthogonal regions. One region will be deticated to manage the TCP/IP stack, another region will manage the Modbus on TCP/IP call the TCP/IP stack API directly (it is running on the same AO so there is not any concurrency problems), another region that manages the cloud communication, and so on. Practically each module of the software that need to call TCP/IP stack will be manage inside an orthogonal region of the main AO.
I'm curious about what you think about that.
Have a nice day!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have implemented similar lwIP requirements by implementing the orthogonal pattern with great success. Where the "main" HSM handles all the TCP/IP stack connection related functionality and only once connected with IP address, then the other orthogonal HSM's comes into play - handling higher layer protocols. Basically your option 2.
Cheers,
Gawie
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Where the "main" HSM handles all the TCP/IP stack connection related functionality and only once connected with IP address, then the other orthogonal HSM's comes into play - handling higher layer protocols. Basically your option 2.
I'll second this. This is exactly how I handle TCP connections. There really isn't much "state" to them other than "connected" and "not connected" so the HSMs tend to be pretty small.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The TCP/IP examples with LwIP in QP/C/C++ have gotten a bit "stale" to say the least and are in big need of updating and general overhaul. I was hoping for some involvement of the open-source community to create some networking examples for QP, but apparently this hasn't happened in more than a decade.
The most natural way to integrate any middleware, like TCP/IP, with QP is with the event-driven approach. (So I would avoid blocking sockets mentioned by Guilio). Interestingly, many TCP/IP stacks are internally event-driven and provide a blocking socket API only to support the ancient "sockets". (Adding blocking is easy, removing blocking is hard.)
Some examples of event-driven TCP/IP middleware include the old LwIP, but there are also modern event-driven, non-blocking approaches, such as Mongoose.
I'm sure that there must be QP users, who also have some experience with communication middleware. Please speak up!
--MMS
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the replies. I was not referring on the blocking sockets. If I need to run two library, that is already able to get the most out using the non-blocking socket, is it better to isolate the TCP/IP stack using a dedicated AO creating some events for opening/closing/sending/receiving or is it better to manage the libraries in a dedicated othogonal region of the main AO that manage also the TCP/IP stack?
Hi all,
I'm studying the LWIP QP example, where the TCP/IP is running on a dedicated AO. I'm thinking what is the best solution if I need to use other protocols that need to use the TCP/IP stack. For example, if I need to use Modbus on TCP/IP, or I need to connect to a cloud to download/publish some information, I need to call the TCP/IP stack APIs. I think I have two possibility:
Create an AO Network Manager to handle the TCP/IP stack. Create some events that can manage the requests to open/close a socket, send/receive data to/from a socket. In this case, I protect the access to the TCP/IP stack and the others AO that need to call a TCP/IP stack API, will post an event to the AO Network Manager.
Create an AO that manage multiple orthogonal regions. One region will be deticated to manage the TCP/IP stack, another region will manage the Modbus on TCP/IP call the TCP/IP stack API directly (it is running on the same AO so there is not any concurrency problems), another region that manages the cloud communication, and so on. Practically each module of the software that need to call TCP/IP stack will be manage inside an orthogonal region of the main AO.
I'm curious about what you think about that.
Have a nice day!
Hi Giulio
I have implemented similar lwIP requirements by implementing the orthogonal pattern with great success. Where the "main" HSM handles all the TCP/IP stack connection related functionality and only once connected with IP address, then the other orthogonal HSM's comes into play - handling higher layer protocols. Basically your option 2.
Cheers,
Gawie
I'll second this. This is exactly how I handle TCP connections. There really isn't much "state" to them other than "connected" and "not connected" so the HSMs tend to be pretty small.
Hi Giulio and Gawie,
The TCP/IP examples with LwIP in QP/C/C++ have gotten a bit "stale" to say the least and are in big need of updating and general overhaul. I was hoping for some involvement of the open-source community to create some networking examples for QP, but apparently this hasn't happened in more than a decade.
The most natural way to integrate any middleware, like TCP/IP, with QP is with the event-driven approach. (So I would avoid blocking sockets mentioned by Guilio). Interestingly, many TCP/IP stacks are internally event-driven and provide a blocking socket API only to support the ancient "sockets". (Adding blocking is easy, removing blocking is hard.)
Some examples of event-driven TCP/IP middleware include the old LwIP, but there are also modern event-driven, non-blocking approaches, such as Mongoose.
I'm sure that there must be QP users, who also have some experience with communication middleware. Please speak up!
--MMS
Hi everyone,
Thanks for the replies. I was not referring on the blocking sockets. If I need to run two library, that is already able to get the most out using the non-blocking socket, is it better to isolate the TCP/IP stack using a dedicated AO creating some events for opening/closing/sending/receiving or is it better to manage the libraries in a dedicated othogonal region of the main AO that manage also the TCP/IP stack?
Last edit: Giulio Dalla Vecchia 2023-11-27
The general idea looks reasonable to me.
--MMS