0

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.

Thanks!

2

You don't need to measure performance here.

Using the loopback does not use any external network at all, hence why it still works even if you're not connected to any external network.

Because of that fact, latency and bandwidth will definitely be lower (in the order of nanoseconds/microseconds versus milliseconds via LAN).

CPU affinity would be a negligible factor here, unless your application is CPU-heavy. If the latter is the case, let the OS decide since it usually makes the best decisions when it comes to resource distribution (i.e. don't worry about it).

Running it as-is and using 127.0.0.1 is cool. A good example of this is a LAMP stack.

Source: been there, done that

  • When I measured elapsed time for acquiring images, and preparing for send over a socket it was comparable to the delay in getting to the remote host. So, CPU load is definitely significant (but not dominating). I'm using Qt on RPI. Should I bother to code to use QLocalSocket versus QTcpSocket? Not sure how to know if that would be significant without doing the implementation – Dave Thomas Feb 6 '17 at 1:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.