Introduction

Much of the work associated with building and managing LayGO devices is routine and can be automated. The LayGO Device Library demonstrates one approach to conveniently handling multiprotocol devices. The approach taken here is based on a device database. The database associates a symbolic device name with an ordered list of protocol services. (The services typically represent a major device, beginning with the physical layer, but the lowest layer might be a virtual circuit. If the lowest layer is a virtual circuit, the major device to which it belongs must be opened and connected first.) The order in which the services are listed in the entry in the device database determines the order in which the service CIDs will be stacked. Information about the structure of the device is maintained in a LDevice data structure relieving the application from much routine record keeping. For instance, the device records the service names so that it can attach to the same services after detaching.

Once a device is constructed, it can be treated as a single entity, despite the fact that it might contain multiple CIDs internally. A device can be opened, connected, detached, attached, disconnected and closed just as individual CIDs are. Stacking and unstacking are done automatically during opening and closing. Device Functions gives a summary of typical device operations.

If the top layer of a device does not use a multiplexed protocol, it is the layer through which data is transferred. Once the device is connected, dev_GetReadWriteCid() will return the CID on which data can be transferred using normal LayGO API functions. For instance, if the device consists of an HDLC LAPB layer on top of an X.21 bis layer, dev_GetReadWriteCid() will return the CID of the HDLC LAPB layer.

If the top layer of a device uses a multiplexed protocol, such as X.25 or Frame Relay, the device does not contain a read/write CID. Data is transferred through minor devices. In this case, lgo_Open() can be used to obtain minor device CIDs through which data transfer will take place. However, a simpler approach is to define devices which consist solely of a minor device. Then the Device Library functions can be used to open and connect the minor device. For instance, a device definition might consist of just an X.25 PVC. In this case, dev_GetReadWriteCid() will return the CID of the PVC which can be used for data transfer.