The LayGO libraries and drivers in version 3.10 are not binary compatible with those of previous versions. Changes to the LayGO API have been minimal, but they will require some minor source code changes and programs will need to be rebuilt. The semantics of the LayGO API functions have not changed, and no change in the logic of programs using the LayGO API is needed. Source code changes are primarily due to renaming of types, constants and macros:
L has been added
as a prefix to each type name. For instance, the LayGO Result
type is now called LResult. An exception is that the CID
type is now called LCid.
lgo_ has been added
as a prefix to each name. For instance, the LayGO STATE_OPEN
constant is now lgo_STATE_OPEN and ERROR_BUFFER_SIZE
is now lgo_ERROR_BUFFER_SIZE.
One substantive change is that the function lgo_InitializeStack() no longer takes any arguments. The parameters that were passed as arguments are now part of the System Stack configuration profile.
The configuration editor, formerly known as edconfig, is now edcfg and wxedcfg, an editor with a graphical user interface has been added. Configuration files from previous versions of LayGO are not compatible with version 3.10.
The LayGO libraries and drivers in version 2.30a are binary compatible with those of version 2.20a. A new version of edcfg is provided to support new configuration features. However, version 2.20a configuration files are compatible with the version 2.30a libraries.
This version incorporates support for 2 new operating systems, Linux and Solaris for SPARC. In addition, support for non-C Language programming environments has been expanded. LayGO now supports programming in Delphi, Java, Perl, Python, Tcl/Tk and Visual Basic, as well as C and C++.
The following changes have been made to the protocol layers:
The X.21 bis layer now allows configuration of physical signals as user signals. User signals are ignored by the physical layer state machine and are set and cleared only at the request of the application. Signals configured as user signals must not be configured as either input or output signals. If either RTS or CTS or both are configured as user signals, hardware flow control must be disabled.
For example, to reserve use of RTS and CTS as user signals, configure the X.21 bis layer as follows:
Input signals = 12 (DSR/Flags) Output signals = 64 (DTR) User signals = 33 (RTS/CTS) Flow control = false
Several new types and macros are defined in phys_api.h to support the new functionality. In addition, 3 new ioctl functions support manipulation of user signals:
The following examples show how to use this new feature. The code assumes that the physical layer has been configured with RTS and CTS as user signals as shown above.
/* Set RTS up */
PhysSignals signal = phys_SIGNAL_RTS;
LBufferSize size = 0;
LResult result = lgo_Ioctl(cid,
phys_IOCTL_SET_SIGNALS, &signal,
sizeof(signal), NULL, &size);
if (result < 0)
{
printf("Error setting DTR up: %s.\n",
lgo_ErrorMessage(result));
}
/* Find out if CTS is up */
PhysSignalData data = 0;
LBufferSize size = sizeof(data);
LResult result = lgo_Ioctl(cid,
phys_IOCTL_GET_SIGNALS,
NULL, 0, &data, &size);
if (result < 0)
{
printf("Error requesting signal data: %s.\n",
lgo_ErrorMessage(result));
}
else
{
PhysSignals signals = phys_SIGNAL_DATA_SIGNALS(data);
PhysSignals config = phys_SIGNAL_DATA_CONFIG(data);
if (config & phys_SIGNAL_CTS)
{
printf("CTS is %s\n",
signals & phys_SIGNAL_CTS ? "up" : "down");
}
}
The LayGO libraries and drivers have been modified in version 2.20a. The new libraries and drivers should not be used with those of prior versions. A new version of edcfg is also provided.
Several new error return codes have been added to the LayGO API:
In addition, lgo_ReadNext() has been changed so that it does not return lgo_ERROR_TRANSMISSION_BLOCKED. This means that applications which are using lgo_ReadNext() exclusively should periodically check the state of all protocol services from which the API has detached. (If a CID has not been detached, lgo_ReadNext() will report an event waiting on that CID should a state changing event occur.)
Previously, virtual circuits could not be opened until the major device to which they belong was in data transfer state. Now virtual circuits can be opened when the major device is in any state.
Previously, lgo_Listen() and lgo_ListenCancel() could fail with the error code lgo_ERROR_TRANSMISSION_BLOCKED. This is no longer true. A listen request is accepted on a CID even if the protocol layer is currently blocked.
The status report structure has been changed. See laygodef.h for the new structure.
The system stack configuration is new. The "maximum major devices" parameters from all layers have been gathered into this configuration. A setting of -1 configures one major device for each physical line detected. A setting of 0 means that no services from this protocol layer will be available. A positive number will configure exactly that number of major devices. The file x25.cfg gives a sample X.25 configuration for X.21 bis, LAPB and X.25.
The stack configuration also contains a list of drivers the stack should use. Previous versions of LayGO allowed the use of only one hardware driver at a time. Now, in Windows 9x and Windows NT, multiple hardware drivers are supported. The file x25multi.cfg contains a configuration to simultaneously run 2 different boards using X.25.
If the driver list is empty, the board type from the SDLC hardware configuration is used as a default list of 1.
In order to support multiple drivers, the driver names have been changed to include a unique identifier. For instance, the Windows NT driver for the LayGO Hardware Emulation driver is now laygont6.sys. All configuration parameters for the drivers are read from the Registry.
The X.21 bis layer allows configuration of physical signals using 3 new parameters. The default settings for X.21 bis are:
Input signals = 13 (CTS/DSR/Flags) Output signals = 96 (RTS/DTR) Flow control = true
The parameters for X.21 would be:
Input signals = 9 (CTS/Flags) Output signals = 32 (RTS) Flow control = false
The parameters for X.21 multidrop would be:
Input signals = 0 (none) Output signals = 0 (none) Flow control = false
The X.21 bis layer now supports NRZI encoding. To use NRZI:
The file nrzi.cfg contains a configuration with these settings.
The HDLC LAPB layer allows configuration of the procedure used to bring up the link. Normally, a connect request results in a SABM being sent. In some cases, a DISC should be sent first. Set the Boolean parameter:
Send DISC before SABM on connect?
to TRUE to enable this option.
The X.25 layer has been changed to be more configurable. The new configuration options provide additional convenience as well as better throughput under a variety of conditions. The new configuration parameters for each service type are shown below.
Maximum number of VCs to activate
This parameter in conjunction with the maximum number of packets to enqueue below limits the amount of time the X.25 layer spends during each activation processing virtual circuits. This currently operates as a Boolean value. 0 places no limit. Any non-zero value stops processing VCs when the down queue is full. (All received packets are processed regardless.)
A non-zero value is recommended when large numbers of VCs (more than 128) will be in use at the same time.
Maximum number of packets requiring acknowledgement
Window status timeout
These parameters control the conditions under which each VC will acknowledge receipt of data packets by sending an explicit RR packet (as opposed to combining the acknowledgement with an outgoing data packet, sometimes called "piggybacking"). If acknowledgement cannot be piggybacked, it is withheld until the number of packets received exceeds the maximum number of packets requiring acknowledgement. For a window size of 2, 0 means acknowledge every packet, 1 means acknowledge only after 2 have been received, 2 or more prevents explicit acknowledgement unless the window status timer expires. Expiration of the window status timer unconditionally generates an RR. The window status timer can be disabled by giving it a length of 0.
Elimination of RRs dramatically improves overall throughput. For applications having constant bi-directional data flow, the maximum number of packets requiring acknowledgement should be set at the window size. A setting of 7 is recommended for SVCs since the window size may be negotiated.
For applications such as file transfer, where the traffic is essentially one way, the maximum number of packets requiring acknowledgement should be set to 0.
Call request timeout
Clear request timeout
When these parameters are non-zero, the SVC will use them to generate lgo_EVENT_CONNECT_TIMEOUT and lgo_EVENT_DISCONNECT_TIMEOUT events if connect and disconnect requests are not responded to within the time limit.
Maximum retries
Maximum number of clear requests to send.
These changes to the X.25 layer configuration make .cfg files which contain X.25 major device or X.25 SVC configurations incompatible with the new version. This distribution contains a new version of the edcfg utility which can be used to create compatible .cfg files. edcfg now supports a -x command-line option which removes any X.25 profiles from the files listed on the command-line. For instance, to remove all X.25 profiles from all files in the LayGO cfg directory, enter:
edcfg -x \laygo\config\*.cfg
The X.25 profiles can then be reinserted as necessary using the -e option.