MESSIP: Message-Passing over TCP/IP

MESSIP implements Message Passing over TCP/IP, using BSD socket interface programming. Three kinds of messages can be sent between Processes or Threads:

• Synchronous Messages (blocking messages), from 0 to 64k in size,
• Asynchronous Messages (non blocking, buffered messages), from 0 to 64k in size,
• Timer messages (one shot and repetitive)

Message Passing consist in the exchange of bytes from one task (Process or Thread) to another (Process or Thread), whatever if these tasks are on the same node or on another node over a TCP/IP network.

The task sending the message is known as the client and the task receiving the message is known as the server. In theory, clients and servers do not need a third agent to communicate between themselves, at least for Synchronous Messages (e.g. messages that do not require to be buffered). In practice, to initiate the communication between clients and servers, it’s necessary to have a third task, which is called ‘messip-mgr’ (the messip manager). Only one ‘messip_mgr’ is necessary on a given network. Further versions of messip will enable to have several redundant managers.

A library (shared) provides the messip API functions that enable to talk to either the messip manager or to the other tasks (either clients or servers).

Each process which wants to use Message Passing must first connect to the messip manager, using the next API function: messip_connect. If no IP address and no port is specified (preferred method), then a text file /etc/messip is used. If this file does not exist, then the default IP name ‘localhost’ is used, and the default port 9000 is used.

In order to receive messages, a server must first create a channel (see API function: messip_channel_create). A channel is identified by a name, which must be unique over the whole network. It’s perfectly fine to create several channels for a given process, but because you can receive messages on one specific channel and this operation is (usually) blocking (i.e. you’ll usually wait until you get a message over this channel), in practice a thread will create and manage only a channel at a time. In the future, it will be possible to receive messages on several channels at the same time. Note that you could poll, but it’s often not very efficient.

Prior to send any message to a server (whatever it is a Synchronous or an Asynchronous Message), a client must find the channel. That means that the server must know the name that identifies the channel. In order to be able to further communicate with the server, that’s the only information that the client must know about the server. The API function to be used is: messip_channel_connect.

Both API functions messip_channel_create and messip_channel_connect involve communication with the messip manager (messip-mgr).

A server typically waits for incoming messages, using the next API function: messip_receive. This is normally a blocking function (but you can specify a timeout value), that means that you exit from this function on these events:

• a message has been received (either Synchronous or Asynchronous): each Synchronous message has to be replied, unless you want to keep the client blocked and waiting for an answer.
• timeout has occurred
• a timer has expired
• a client which was connected has either died or closed the connection to the channel.

A client sends either Synchronous or Asynchronous Messages:

• a Synchronous Message is blocking: that means the client will wait until the message is received by the server and processed. The server has to reply to the client in order for the client to be unblocked. Note that you can specify a timeout. Synchronous Messaging do not involve the Messip manager (messip_server agent), only the server and the client talk together. Sending a Synchronous message is performed with the next API function: messip_send
• an Asynchronous Message is non blocking. That means that a client can’t ignore the state of the server. Because of this, there is no reply from the server. Therefore, you can’t assume that the message has been received by the server. When the server has created the channel (where he receive messages), he has specified a parameter which is the maximum number of messages that can be buffered. Asynchronous Message are slower than Synchronous Message because they are copied twice: from the client to the Messip manager, then from the Messip manager to the server.

See also:

messip_disconnect(), messip_channel_create(), messip_channel_disconnect()

---