Skip to content

routing

bergsma edited this page Jul 31, 2014 · 2 revisions

Routing

AutoRouter routes messages between target applications, such as AutoMan and HS. Any process that understands the Ab Initio Protocol can use AutoRouter services.

Connections are established using the AutoRouter CONNECT method. Connections will time-out after a period of inactivity

Remote Routing

A single AutoRouter handles all remote messages to clients on the node. (More than one AutoRouter is not required or supported.) The AutoRouter network is strictly point-to-point; if a message needs to be routed to a remote node, the AutoRouter will attempt a direct point-to-point connection with an AutoRouter on the remote node. This is a dynamic connection method, since AutoRouter does not need to be connected to the remote node prior to the message being received by AutoRouter. There is also an advantage if a link dies, as the dynamic re-connection method will be transparent to the processes that are communicating.

Local Routing

Within the VMS and UNIX environment, AutoRouter uses a half-duplex communication method to route messages to and from local processes. This approach allows local processes to send and receive messages using a simple file stream interface, so that AutoRouter can be used by virtually any type of programming or interpretive command shell language.

From the perspective of local client applications, all outgoing messages are written to a single write-only device owned by AutoRouter. This device is called "MBX_ROUTER". A local client application reads all incoming messages from a unique read-only device created by AutoRouter on behalf of the client. This device is called MBX_target where the target is the unique target name of the client application.

VMS

In VMS, the devices used are mailboxes. The MBX_ROUTER mailbox is defined system-wide, so that all processes on the node can write it. A client application with a target name of instance.object would access the mailbox MBX_INSTANCE_OBJECT. The VMS mailboxes can be accessed using standard file I/O, as the following DCL example illustrates: _

$ open/write outgoing MBX_ROUTER
$ write outgoing "|instance.object|event|connect|sender|"
$ close outgoing

$ open/read incoming MBX_INSTANCE_OBJECT
$ read incoming message
$ close incoming

_

AutoRouter VMS Mailboxes

UNIX

In UNIX, the devices used are POSIX FIFO pipes. The router pipe is actually located as a file inode, defined as "$AUTOFIFO/router". A client application with a target name of instance.object would access the $AUTOFIFO/instance_object FIFO inode. Accessing the FIFO pipes should be done using standard UNIX I/O.

Inactivity

If a device does not have any message activity for 10 minutes, AutoRouter will unlink from it. This is not fatal to the local process if it still has the device opened for reading; a message arriving after AutoRouter has unlinked from the device will cause AutoRouter to re-establish the link, and the message will be delivered. Only when both the local process and AutoRouter have closed and unlinked from the device will it actually be deleted. (See Also: DISCONNECT method.)

Clone this wiki locally