TCP/IP multiplatform basic communication component

I want to contract a basic communication component handling low-volume, ca. 20-byte command messages with lenient performance requirements. There will be two versions of the component with shared functionality. One will be a “client” one and the other will be a “server” one. The main communication between the client and server components should take place in Wi-Fi (typical local single router) network over the TCP/IP or UDP (as recommended by the contractor). The server component will handle additionally some I2C and UART 2-way interfacing. The components should work in the following OS-s: • Client: a multiplatform one, at least Android, Linux and Windows environments, optionally in iOS if including iOS into in a common multiplatform project is possible without a significant increase in the dev project complexity and cost • Server: Linux only Test HW platforms: • The target Linux environment will be Raspberry Pi Zero 2W • Android: tests are planned to be performed on Samsung Galaxy J3 and/or A32 • Windows: the component should work at least in Windows 10 and 11 The communication will be tested between a client and server component where the server will run on Raspberry Pi Zero Linux (“server”) and the client on different devices on Android/Windows/Linux (“clients”). The sending and receiving code should execute possibly in the background in particular in the case of Linux “server” in order to allow to use the host Linux platform to perform other processing in parallel. The shared “Wi-Fi” communication part of both versions of the component should be 2-way and use simple circular queues to buffer RX and TX messages. I have attached a draft, base class Qued with a very simple own implementation of such a circular message queue. The class needs to be provided with missing code for the TCP/IP or UDP interface handling and preparing the contents for the existing PUT_MSG method. The contractor can freely propose changes or a different implementation of this queue mechanism. The client version should have only an RX and TX Wi-Fi queue with no additional processing needed, just handling the communication and queues. The server component should have an RX and TX Wi-Fi, RX and TX UART as well as RX and TX I2C queues with no additional processing needed, just handling the communication and queues for all components except RX Wi-Fi and RX I2C. The server logic for Wi-Fi RX handling is additionally described stepwise below: 1 Listen for Wi-Fi RX messages, receive the message packets 2 Put all messages into the RX-WIFI queue. 3 Put all messages also in the TX-UART and TX-WIFI (for all detected clients network IP-s) queue 4 Check the first two 1-byte characters of the message that define the message type and If the 2 bytes are 0x58, 0x02 then put the message also into the TX-I2C queue In the case of RX I2C the messages from this queue once received should be put into the TX-UART queue. The project should also include additional server and client functions that will allow the client to automatically detect the address IP of the server (on the same router) by the clients, like UPnP or some other, possibly simple but reliable custom method. Additionally the server should collect the IP of the clients that are currently active to be used to enable communication in the opposite direction. As part of the offer I would like to ask for a proposition of the approach to the component development, in particular: • Is it worth and if so how to address multiplatform development to achieve possibly easiest common development and subsequent modifications, especially what e.g. libraries, framework, dev environment to use • What mechanism to use for server detection and 2-way communication setup and maintenance by the server and clients Please include also the descriptions of similar projects delivered.