I have a Client/Server application where the Server runs on one rpi and communicates with a client running on another rpi. They communicate using Tcp Sockets.
I'm going to do a spin-off application where a single processor is used for the function of both the client and the server.
The easiest implementaion would be use the code that runs on the client pretty much "as is" and run it on the same rpi that hosts the server. Communication between the client and server code with be over the local loopback, 127.0.0.1
I'm wondering if the inter-process communication (using sockets) on the same rpi would then be limited by ethernet speeds? Or, is the ethernet hardware bypassed completely if communication is over a local loopback interface?
Latency between when the server sends data to when the client receives (and processes) the data is critical. So, if that latency would be significantly reduced by writing a new application that has the equivalent of the client and server running in the same process, I'll want to do that.
Trouble is, I won't know unless I do the work to implement both approaches then compare the performance. Unless someone has "been there, done that!".
Also, CPU resource could be an issue. Does communicating through local loopback impact CPU usage more/less than other forms of inter-process communication?
Also, are there any tricks to get best hardware utilization of two processes that run simultaneously? Like a way to make sure they run on separate processors?
Pointers to relevant articles would be appreciated.