Pipe messaging
Pipe messages format and workflow for command and event pipes for better understanding the process of the communication between app and service. Core project is doing it for a client application.
Last updated
Was this helpful?
Pipe messages format and workflow for command and event pipes for better understanding the process of the communication between app and service. Core project is doing it for a client application.
Last updated
Was this helpful?
Both command and event pipes use the same message format.
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 is designed to process one request per client connection in one thread. When a new client is connected, the pipe server waits 3 seconds for a request and if no request comes then the pipe server does force disconnect for the connected client.
Note that some requests could require a lot of time to process.
Event flow is designed to work with one permanent connected client with regular handshakes for the pipe health check.
Client sends the first handshake right after connection and it allows to check that client can send and service can read pipe messages. If the service doesn't read a handshake message in 1000 msec then it uses force disconnect for the client. Then the service sends a handshake from its side and the client checks that it can read messages from the service.
Core project uses 3000 msec as default timeout. If there is no successful handshake then the client should be disconnected, disposed of and created a new one.
After successful initial handshake, service wait's for the event to send. If no event comes in 1000 msec then the service sends a handshake to the client to check that the client is still available and awaits a handshake from the client. If a secondary handshake fails for any reason then the service disconnects a client and waits for a new one.
When a new event comes in 1000 msec then the service sends the event message to the client and awaits an event confirmation message from the client to confirm delivery. If confirmation failed and there was no TrafficChanged event then Service disconnects the client, waits for a new one and the event message stays in the delivery stack to send it again.
TrafficChanged events don't save in the delivery stack because they come every second and there is no critical information to send every missed event.
