A pipe is the core component for linking together a connection with a set of flows and optionally default transformations and notifications. The connection defines the remote messaging system where messages will be sent to and received from.
When a pipe is created, a name is required. When a pipe is connected, it appears to the end points as a client connection. Consequently, the pipe name must be unique to avoid any clashes with other pipes and clients that may already be connected. When connecting locally, the client ID is the name of the pipe appended to bridge:
. This should minimize any clashes with regular clients. When connecting to a remote broker, the clientID
is simply the pipe name. Thus, a pipe called myPipe
will have a client ID of bridge:myPipe
on the local micro broker and myPipe
on the remote broker. Therefore, if two brokers are connected through a bridge and both contain a pipe with the same name, there will be no clashes. Hence, the client ID bridge:pipeName
is reserved for the bridge.
Care must taken, however; if two brokers have a pipe with the same name and are connected to a third broker, as there would be a clash.
When a pipe is connecting to a remote broker, it is treated as a regular client, and as such, the clientID
can not exceed 23 characters in length. When creating a pipe, a name of greater than this length will not be accepted.
When a pipe is created for the first time, it will need to be explicitly started. Whether the pipe actually connects to the remote peer or not depends on the configured transmission control policy for the given bridge.
When the pipe has started, it subscribes to any topics and queues locally or remotely. If the pipe's remote connection is broken, messages will continue to be queued at both ends until the connection is re-established. When a pipe is stopped, the pipe will stop consuming messages within the micro broker. Stopping the remote connection is handled using transmission control.
When a pipe is deleted, an attempt to purge the pipe is also made. This ensures that no state is held at either the local or remote end. Failure to delete the pipe cleanly could cause another pipe connecting with the same name to a remote endpoint to receive messages it had not subscribed to. There is an option to force a delete without ensuring a clean up but this is only recommended as a last resort if the remote endpoint has changed, and for example, and could never be connected to.
Parent topic: Components of the bridge: XPD621