LayGO Frequently Asked Questions
- I issue a connect request on an X.25 SVC but never get a response. What's the problem?
- How do I pass the address, facilities and user data for an X.25 call request on an SVC?
- In the buffer pool configuration, what are reference buffers and when are they needed?
- How do I give devices in the same layer different configurations?
- After writing a few times, I start getting lgo_ERROR_WRITE_QUEUE_FULL. What am I doing wrong?
- How do I send X.25 interrupt and interrupt confirmation packets?
- Are the LayGO libraries thread-safe?
- Are the LayGO libraries Y2K compliant?
- I'm sure the driver is installed, but lgo_InitializeStack() always fails with lgo_ERROR_DRIVER_NOT_INSTALLED. What's the problem?
Answers
- 1. I issue a connect request on an X.25 SVC but never get a response. What's the problem?
- 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 pckets, 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.
Top
- 2. How do I pass the address, facilities and user data for an X.25 call request on an SVC?
- 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.
Top
- 3. In the buffer pool configuration, what are reference buffers and when are they needed?
- 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.
Top
- 4. How do I give devices in the same layer different configurations?
- 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 edcfg 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.
Top
- 5. After writing a few times, I start getting lgo_ERROR_WRITE_QUEUE_FULL. What am I doing wrong?
- 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.
Top
- 6. How do I send X.25 interrupt and interrupt confirmation packets?
- 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 lgo_EVENT_PROTOCOL_MESSAGE events.
Top
- 7. Are the LayGO libraries thread-safe?
- The LayGO libraries for all platforms are thread-safe
under 2 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.
Top
- 8. Are the LayGO libraries Y2K compliant?
- 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.
Top
- 9. I'm sure the driver is installed, but lgo_InitializeStack() always fails with lgo_ERROR_DRIVER_NOT_INSTALLED. What's the 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
cfg directory (where x is the board ID) contains the
configuration you need.
Top