Virtual Circuits Overview

In his classic textbook, Computer Networks, Andrew Tanenbaum describes virtual circuits by analogy with a public telephone network:

The telephone customer must first set up the virtual circuit (dial the call), then transmit the data (talk), and finally close down the circuit (hang up). Although what happens inside the telephone system or subnet is undoubtedly very complicated, the two users are provided with the illusion of a dedicated point-to-point channel between themselves. In particular, information is delivered to the receiver in the same order in which it is transmitted by the sender.

Rendezvous virtual circuits provide a similar quality of service. A virtual circuit is an exclusive, monitored connection between two terminals—each of which is a virtual circuit transport object.

•

The two terminals communicate exclusively with each other. They do not communicate with any other transport object.

•

Each terminal can send messages to the other terminal. Messages arrive in the same order as the opposite terminal sent them.

•

Each terminal monitors the connection to ascertain continuous correct operation.

•

A failure anywhere along the circuit causes the entire circuit to cease functioning.

—

Each terminal presents a VC.DISCONNECTED advisory message.

—

The terminals can no longer deliver inbound messages to listener objects.

—

Attempting to send outbound messages produces error status.

—

The terminals cannot reconnect. Programs must destroy them, and all listener objects that use them. To establish a new virtual circuit, programs may create new terminal objects.

The scope of a virtual circuit transport is limited to exactly one other transport—the terminal at the opposite end of the connection. No other transports receive messages sent on the virtual circuit—not even transports that communicate on the same network and UDP service as the virtual circuit terminals. Conversely, terminals of a virtual circuit do not receive messages sent by any other transports.

A program can create any number of listener objects that use a virtual circuit transport object. They can listen on inbox names or on public subject names. In either case, they can receive only those messages sent by the opposite terminal.

Similarly, a program can specify the destination of an outbound message using either an inbox name or a public subject name. In either case, the message travels point-to-point to the opposite terminal.

Every virtual circuit terminal employs an ordinary transport object as an underlying communication mechanism. The transport can be an (rvd) network transport or the intra-process transport. (Several virtual circuits can employ the same transport. The transport can carry other messages as well.)

The transport carries both data and protocol communications for the virtual circuit. All such communication travels point-to-point between the two terminals. The terminals multiplex inbound messages to appropriate listener objects.

A hidden protocol establishes and monitors the connection between terminals.

Terminals present advisory messages to programs to report changes in the connection’s status.

Because virtual circuits rely on point-to-point communication between the two terminals, they can use direct communication to good advantage. To do so, both terminals must employ network transports that enable direct communication. For an overview, see Direct Communication.

See Also

Andrew S. Tanenbaum, Computer Networks, 1981, Prentice-Hall, Englewood Cliffs, New Jersey.