Pipe Messaging

Pipe messaging is a communication protocol that defines specific formats and workflows for command and event pipes. This system helps track and understand how messages flow between applications and their associated services. Our Core project is currently implementing this pipe messaging approach for a client application to manage their service communications.

Message format

Both command and event pipes use the same message format.

Field	Length	Description
Length	4 bytes	Message length in big-endian format
Message	up to 2 147 483 647 bytes	Payload in XML or JSON format

All message schemas can be found in the file RPSchema.xsd.

Command Pipe

The Command Pipe processes a single request per client connection using one thread and works with only one client at a time. When a client connects, the pipe server will wait for 3 seconds to receive a request. If no request is received within this timeout period, the pipe server will forcibly disconnect the client.

Command pipe flow

Note: Request processing times may vary significantly depending on the complexity of the operation.

Event Pipe

The Event Pipe is designed to maintain a persistent connection with a single client, utilizing regular handshakes for pipe health monitoring.

The connection process begins with an initial handshake sequence. The client initiates this sequence immediately upon connection, verifying bidirectional communication capability between client and service. If the service fails to receive this handshake message within 1000 milliseconds, it forcibly disconnects the client. Following successful client handshake reception, the service sends its own handshake message to verify the client can receive messages.

The Core project uses a default timeout of 3000 milliseconds. If a handshake is not successful within this period, the client will be disconnected, disposed of, and a new client instance must be created. The creation of this new client instance is also managed by the Core project.

After the initial handshake completes successfully, the service enters an event-waiting state. If no event occurs within 1000 milliseconds, the service initiates a secondary handshake with the client to verify connection stability. This secondary handshake requires client acknowledgment. Any failure in this secondary handshake process results in client disconnection, after which the service begins waiting for a new client connection.

When an event occurs within the 1000-millisecond window, the service transmits the event message to the client and awaits a delivery confirmation. If confirmation fails and the event was not of type TrafficChanged, the service disconnects the client and begins waiting for a new connection. In this case, the event message remains in the delivery stack for retransmission to the next client connection.

TrafficChanged events are not stored in the delivery stack since they occur every second and do not contain critical information that requires tracking of missed events.

Event pipe flow