Service Control

When a service is initially opened, it expects to receive all commands and data directly from the API via the CID which identifies it, and it passes all protocol events (both data and control events) to the API via the CID. When another service is pushed onto the first, the situation changes. The first service still expects to receive commands from the API via its CID and to pass protocol control events to the API via its CID. But data is expected to be received only from the layer above. So any data received is assumed to belong to a higher layer protocol and is passed to the layer above. Each layer considers both data and control events from the protocol layer above as just data to be transmitted. Whether the bytes represent protocol commands or user data is not known and not relevant. Similarly, the layer passes any data it receives to the protocol above without any knowledge of how the data will be interpreted by higher layer protocols.

In the normal course of operation, data will be read from and written to only the CIDs representing the highest layer in the device. However, LayGO does not prevent data from being written directly to intermediate layers, if the application chooses to do so. This is useful for debugging since invalid frames or packets may be inserted at the physical layer to see how they are handled by higher layers. When the data is received by the physical layer at the remote site, it will be passed as data to the layer above.

Once the service has been placed in data transfer state, it normally makes every effort to remain in data transfer state unless disconnected by the remote site. For layers not on top of the device, there may be little or no event traffic for the application to monitor. In this situation, the application may call lgo_Detach() to indicate that the service is to continue operations without reporting control events. lgo_Detach() invalidates the CID. A new CID will be issued by the system when the application calls lgo_Attach() to regain active control of the service. lgo_Attach() must be called with the same service identifier that was originally passed to lgo_Open() to open the service.

If the application does not detach from a service, it must regularly monitor the CID for events because each event occupies a system buffer while waiting to be received by the application. A shortage of buffers can slow or halt the system. For example, if the physical line is noisy, the link layer may reset frequently because of lost or damaged frames. This will cause a lgo_EVENT_RESETTING event when the reset starts and a lgo_EVENT_RESET_COMPLETED event when the reset ends. These events are queued for the application if the application has not been detached from the link layer CID. Resetting is a normal part of the protocol, causing only a short pause in data traffic. The protocol can get back to data transfer state. However, unprocessed events consume system resources threatening the ability of the entire system to continue operating.