Connecting Devices

Once the device has been assembled, each layer must establish a connection with its peer protocol layer at the remote site before data transfer can begin. The application can attempt to establish a connection using either lgo_ConnectRequest() or using lgo_Listen(). lgo_ConnectRequest() actively attempts to bring up the connection in a manner appropriate to the protocol while lgo_Listen() puts the service into a receptive state waiting for the remote site to take the initiative. For instance, on the LAPB layer, lgo_ConnectRequest() will result in a SABM frame being transmitted after which the layer will wait to receive a UA. In contrast, lgo_Listen() informs the layer to respond to any SABM it receives with a UA. If the service is configured to do so, it will time out if it does not receive a response to its request within a specified time. If the service is listening, it will not time out. It will wait until a connect request is received or the application calls lgo_ListenCancel().

To actively establish the connections with lgo_ConnectRequest(), the application must work from the bottom up. Obviously the link layer cannot send the control frames needed to bring up the link until the physical connection has been established to carry the frames, and the packet layer cannot send packets until the link is established. To passively establish a connection with lgo_Listen(), the application should work from the top down. This insures that the upper layers are ready to receive an invitation to establish a connection as soon as the layers below are connected. The connections will still be established from the bottom up.

In the dlaygo sample program, the dlg_ConnectLayer() function attempts to bring up a connection using lgo_ConnectRequest(). Note that the success of a call to lgo_ConnectRequest() does not mean that a connection has been established. It simply means a request is being issued, that is, that the appropriate steps for establishing a connection have been initiated. The application must wait for an event from the remote site indicating acceptance or refusal of the connection request.

Note: Some protocols, such as Frame Relay, may not be "connection-oriented". The application must still call lgo_ConnectRequest() or lgo_Listen() to notify the layer that it may begin operations and then wait for a control event. In the case of lgo_ConnectRequest(), the layer will simply respond immediately with an lgo_EVENT_CONNECTED event. In the case of lgo_Listen(), the layer will respond with a lgo_EVENT_CONNECTED event as soon as the first data packet is received.

When the application is finished with a device, layers should be disconnected by calling lgo_DisconnectRequest(). Layers are always disconnected from the top down. This is required so that lower layers in the device, which are required to transmit the disconnect requests of higher layers, remain in data transfer state. However, LayGO does not enforce this requirement. If the application wishes to disconnect the link layer while the network layer is still in data transfer state, it may do so. But the network layer will not be able to gracefully shut down its connections.

If the remote site fails to respond to a lgo_DisconnectRequest() call and a disconnect timeout has not been set, the application may call lgo_Reopen() to bring the affected service into the open state. dlg_DisconnectLayer() in the sample program illustrates this process.