Daemon Parameter

The daemon parameter instructs the transport creation function about how and where to find the Rendezvous daemon and establish communication.

Each Rendezvous transport establishes a communication conduit with the Rendezvous daemon, as the following steps describe:

The daemon process opens a (TCP) client socket, and waits for a client to request a connection.

The -listen option of the Rendezvous daemon (rvd) specifies the socket where the Rendezvous daemon should listen for new client program connections.

The program calls the transport creation function, which contacts the daemon at the client socket specified in its daemon parameter.

The daemon parameter of the transport creation function must correspond to the -listen option of daemon process; that is, they must specify the same communication type and socket number.

If no daemon process is listening on the specified client socket, then the transport creation call automatically starts a new daemon process (which listens on the specified client socket), and then attempts to connect to it.

The daemon process opens a conduit for private communication with the new transport object in the program. All future communication uses that conduit.

The request socket is now free for additional requests from other client transports.

Specifying a Local Daemon

Specify the daemon’s client socket as a character string with components separated by colons.

For local daemons, specify the transport creation function‘s daemon parameter and the ‑listen option to the daemon process as a (TCP) socket number; for example: "6555"

To use the default client socket, supply NULL as the daemon argument to the transport creation function, and omit the ‑listen option to the daemon process.

Remote Daemon

In most cases, programs connect to a local daemon, running on the same host as the program. Certain situations require a remote daemon, for example:

•

The program runs on a laptop computer that is not directly connected to the network. Instead, the laptop connects to a workstation on the network, and the daemon runs on that workstation.

•

The program connects to a network at a remote site.

For remote daemons, specify two parts (introducing the remote host name as the first part):

•

•

When a client specifies a remote daemon that is not present, the client does not auto-start a daemon in that remote location.


	Direct communication is not available when connecting to a remote daemon (see Direct Communication).

Suppress Daemon Auto-Start

The policy that a transport cannot automatically start a remote daemon also results in a convenient way to suppress the auto-start feature of a local daemon. To do so, specify the local daemon with a two-part parameter, as if it were a remote daemon. For the first part (the host) supply either the local computer’s loopback address, 127.0.0.1, or the local host name (if the host does not support a loopback address). For example:

127.0.0.1:7500

my_host_name:7500

Secure Daemon

To connect to a secure daemon, specify three parts:

ssl:host:port_number

For example:

ssl:myhost.net:8344

ssl:102.24.12.3:8344

Colon characters (:) separate the three parts.

ssl indicates the protocol to use when attempting to connect to the daemon.

host indicates the host computer of the secure daemon. You can specify this host either as a network IP address, or a hostname. Omitting this part specifies the local host.

port_number specifies the port number where the secure daemon listens for TLS connections. This part is required; you may not omit it.

Two Identical Arguments

Programs that connect to a secure daemon must specify an identical three-part string to two API calls:

•

The daemonName parameter of the call that registers the secure daemon’s certificate—see Secure Daemon

•

The daemon parameter of the call that creates the transport object that connects to the secure daemon