UDP for interprocess communication

Question

I need to implement an IPC mechanism (sending short messages) between a java / C ++ / python process running on the same system. One way to implement this is to use a socket using the TCP protocol. This requires maintaining the connection and other related activities. Instead, I am considering using UDP, which does not require a connection, and I can send messages. My question is that UDP on the same computer (for IPC) still has the same drawback if it is applicable when communicating between machines (for example, unreliable packet delivery, the packet is out of order.

Answer 1

Yes, still unrealistic. For local communication, try using named pipes or shared memory

Edit:

You do not know the requirements of your applications, did you consider something like MPI (although Java is not supported well) or, Thrift? ( http://thrift.apache.org/ )

Answer 2

Local UDP is still unreliable, but the main advantage is UDP multicast. You can have one data publisher and many subscribers. The kernel performs the task of delivering a copy of the datagram to each subscriber for you.

On the other hand, local Unix datagram sockets should be reliable, but they do not support multicast.

Answer 3

Local UDP is more unreliable than on the network, for example, 50% + packet drops are unreliable. This is a terrible choice, kernel developers attribute quality because of a lack of demand.

I would recommend exploring message-based middleware, preferably with a BSD-compatible interface for an easy learning curve. The proposal will be ZeroMQ , which includes C ++, Java, and Python bindings.

Answer 4

Local UDP is still unreliable and is sometimes blocked by firewalls. We encountered this in our MsgConnect product, which uses local UDP for inter-protocol communication. BTW MsgConnect may be an option for your task, so you don't need to deal with sockets. Unfortunately, there is no Python binding, but there are "native" implementations of C ++ and Java.