Routing PlugIn Help

Robustly connects one RBNB server to another. The "parent" server can see and access the "child" server as if the entire contents of the child were a source to the parent.

Input arguments

-a	Parent server address (e.g. localhost:3333)
-b	Child server address
-t	Connection timeout (msec)

Description

This works similar to how the built-in server routing, or more closely, "shortcuts" work, but via modular external plugins. Relative to built-in server routing:

Each route is one-way, i.e. routing parent to child means parent can see and access child, but child cannot access parent. At the interface level, a plugin connection is made to the parent that reflects the contents of the child. The child only sees a sink connection. For two-way connections, use a pair of routing plugins.
Streaming is not yet fully supported. Streaming (pushing data) via routes has always been a difficult problem. The routing plugin approach provides a better testbed from which to develop and test new approaches to this.
Routing can be established after-the-fact. I.e. it does not need to be decided upon at RBNB server startup.
Routing via plugins does not establish a rigid hierarchy, i.e. paths to data are relative. This is more flexible, but also can be more difficult to know how to find certain data.
Routing can be accomplished from third-party machines. E.g. a machine in Hanover NH can establish the route between an airborne server flying over Alaska and a ground based server in California.

Disruption Tolerance

Network connections can fail in a number of ways to a number of disruptions. Putting the routing logic in a plugin makes it possible to more readily experiment, test, and tailor disruption tolerant routing logic.

Old Logic

Earlier attempts at disruption tolerance (e.g. the routing built into the RBNB server) used an approach something like:

Try to sustain good connections (keep-alive pings)
Detect connections when they go bad (status requests)
Try to repair bad connections when they are detected (exception handling)

This approach has met with several difficulties:

Bad connections cannot always be avoided
It is difficult or impossible to detect some bad connections
Trying to repair a connection can lead to more problems

New Logic

The robust routing plugin takes a new approach:

Stateless design that doesn't depend on maintaining connections
Presume idle connections are bad, regardless of status
Discard and restart connections

There are several types of connections that this plugin makes:

Server connections (to parent)
Server connection (to child)
PlugIn client connection (to parent server)
Sink client connection (to child server)

If a parent server connection goes down, for example the RBNB server itself aborts, the plugin goes into a sleepy loop attempting to reconnect.

If a child server connection goes down, the current sink-request handler aborts, but the next incoming request will automatically create a new sink connection.

PlugIn connections are periodically automatically restarted based upon the timeout period. Successful activity resets the timeout clock so as to retain proven connections for efficiency. Inactivity for the timeout period causes the plugin to automatically close and reopen its plugin connection. Thus, even if a connection has an undetected problem, it is automatically repaired at the next reconnect interval.

Sink connections are implemented as separate threads to handle multiple simultaneous requests in parallel. Sink threads are put in a stack to be re-used only if they have successfully completed the previous request. A sink thread is considered stale and is discarded if it has not been used in the specified timeout period. Thus, bad or hung connections are abandoned, yet good connections are sustained for efficiency.