Resolution:
  A virtual circuit is created on top of a network transport object.  That object can, in certain circumstances, be a transport which is enabled for direct communication.  A terminal of a virtual circuit receives messages by point-to-point communication exclusively from the other terminal.  If the virtual circuit is broken, it cannot be reconnected.  In order to re-establish communication, the virtual circuit objects must be destroyed and both endpoints need to take action to create a new virtual circuit.
  
  Direct communication allows applications to conduct communications without intervening rvd processes.  To enable a transport object for direct communication, it is created using a two-part service parameter with the first part specifying the service port for regular communications and the second specifying the port for eligible communication.  A message will be transmitted directly if and only if both publisher and subscriber use direct-enabled transports, there is no intervening routing daemon, and the message has an inbox subject.  A direct-enabled transport is not limited to direct
communication.

  Our current tibrvclient/tibrvserver examples can be used with direct-enabled transports by specifying the "-service" argument appropriately.  No code change is required.

For direct communication, only the appropriate service parameter is required, provided that the applications run on the same subnet, do not connect to remote daemons, and use inbox subjects.

The service is specified as
    &ltregular service>:&ltdirect port>

If specified without naming the direct service port (e.g., 7500:) then an ephemeral port will be used.  If the direct port is specified, it must be unique on that host.  Communication which passes through an rvd uses the regular service port.  Direct point-to-point communication uses the direct UDP port.  Only inbox subjects are eligible for direct communication.  Thus the client/server examples (which use inbox subjects) can utilize direct communication, but the tibrvsend/tibrvlisten examples (which use ordinary subject names, specified by the user) cannot.  It is legal to use a direct-enabled service for tibrvsend and tibrvlisten, but the message(s) will still pass through daemons.