You may be calling on an unassigned Logical Channel Number (LCN). On an SVC, the LCN is assigned at the time the call request is made. The X.25 protocol requires that the calling DTE choose the highest available LCN to call out on. If the DCE is calling, it must use the lowest available LCN. This is required in an attempt to avoid "call collisions" where the DCE and DTE call each other on the same LCN at the same time. If the DTE and DCE do not agree on the number of PVCs and SVCs, they will disagree on which LCNs are available for SVCs.
When the network gets a call request on an unassigned LCN, its only response may be to send a diagnostic packet on LCN 0. This diagnostic packet is processed by the X.25 major device. Nothing is sent on the unassigned LCN. To receive the diagnostic packets, don't detach after connecting the X.25 major device. Issue the connect request on the CID of the SVC. Then check for events on the CID of the major device. Any diagnostic packets will be passed to the application as "Protocol Message" events.
The fix is to make sure that the configuration settings for the number of PVCs and SVCs used by the major device match those used by the network provider.
Simply pass the data encoded data as an array of bytes to lgo_ConnectRequest(). LayGO®'s X.25 call library provides on-the-fly encoding capabilities. The utility program edcall allows predefined call request packets to be encoded and stored on disk and then loaded at runtime.
Layers which are "error free," such as the HDLC LAPB layer, must keep a copy of each transmitted frame until it is acknowledged as received. If it is not acknowledged, it can then be retransmitted. Reference buffers allow copies to be made without actually copying the data. This saves both time and space.
When using an error free layer, each device needs as many reference buffers as there are possible unacknowledged frames. For HDLC LAPB, this is the size of the window.
The function lgo_ConfigureStack() uses named configuration files to set the default configurations for each layer. When a device is opened, it automatically gets the default configuration. There can be only one default. (A "default" default configuration is compiled into the code for each layer. If a new default is not set with lgo_ConfigureStack(), the compiled in default is used. The compiled in default values are those suggested by edconfig when creating a new configuration.)
Devices can also be configured individually using lgo_LoadConfiguration() and lgo_SetConfiguration(). The device must be in the open state to be configured.
Nothing! The size of the write queue is designed to pace the speed at which the application writes to the speed of the communication link. The speed at which the PC can generate data is several orders of magnitude greater than the speed at which it can be transmitted over the link. Limiting the number of writes which can be enqueued on each CID helps insure fair access to system buffers. You can set the size of the write queue in the System Stack configuration.
Use lgo_Ioctl() with function codes pkt_IOCTL_SEND_INTERRUPT and pkt_IOCTL_SEND_INTERRUPT_CONFIRMATION. You can attach up to 128 bytes of user data to an interrupt.
Interrupt and interrupt confirmation packets are delivered to the application as EVENT_PROTOCOL_MESSAGE events.
The LayGO® libraries for all platforms are thread-safe under two conditions. First, functions which affect the stack as a whole (primarily the supervisory functions) must be single threaded. Second, a given CID must not be accessed by more than one thread at the same time. If a single thread handles both reading and writing for each CID, the LayGO® libraries will take care of the interthread synchronization. If one thread is to read and another to write on the same CID, the application will have to provide its own explicit synchronization with a mutex or critical section to assure that each function call on a given CID is completed before the next is executed.
Absolutely. The LayGO® libraries do not do any date computations or manipulations. They never even read the date or time from the system real-time clock. Since there is nothing about the absolute date or time which matters to the software, there can be no problem related to the change of century in LayGO® library code.
For the purpose of running timers, the LayGO® protocol stack keeps its own internal representation of the time. Stack time is represented as an unsigned binary integer using 48 bits on 16-bit platforms and 64 bits in 32-bit platforms. The time is kept in milliseconds and restarts at 0 every time the stack is initialized. This means the stack can run continuously for thousands of years (16-bit platforms) or billions of years (32-bit platforms) before the code would encounter a "wrapping" problem analogous to the Y2K problem.
Did you configure the stack to use the installed driver? By default, the stack tries to open the hardware emulation driver (board ID 6). If you want to use a different driver, you must specify which one(s) you want to use in the System Stack configuration. The stackx.cfg file in the LayGO® config directory (where x is the board ID) contains the configuration you need.