Chapter 3: CCIIPX Configuration

CCIIPX is supported on Windows 95, Windows 98 and Windows NT systems only.

3.1 CCI Support for Novell NetWare IPX

3.1.1 CCI Support Modules for IPX

In order to enable CCI support for the Novell NetWare IPX transport, one executable module is provided:

CCIIX32.DLL - which enables the CCI interface routines necessary for CCI equipped machines to communicate with each other. MERANT products use this (and other protocol-specific CCI modules) so that they do not need to worry about the complexities of the underlying network protocol.

3.1.2 Novell NetWare IPX Configuration

There is no specific configuration of the Novell NetWare or operating system environment required to run CCIIPX, however there are restrictions on the supported IPX protocol providers which can operate with CCIIPX, these differ between operating systems.

Microsoft Windows 95.

CCIIPX v3 requires Novell's Client32(tm) NetWare Requester support as shipped by Novell. Use of Client32 version 2.20 or later is recommended.

Microsoft Windows NT.

CCIIPX v3 requires Novell IntraNetWare Client for Windows NT(tm) v4.0a or v4.10 as shipped by Novell.

CCIIPX cannot use the Microsoft IPX compatible transport as shipped with Windows 95 or Windows NT, these IPX transports do not provide the interface support level required for CCIIPX.

3.2 Configuring CCIIPX Parameters

3.2.1 CCI.INI File Options for CCIIPX

You can tune CCIIPX using the tuning options described below. You set the ones you want to change in the file CCI.INI.

Why would I need to use any CCI.INI options?

The CCIIPX module has been developed to be a reliable and easy to configure protocol option in the CCI suite. In almost all circumstances CCIIPX will work correctly straight out of the box with no need to configure anything. If however some system tuning is required the following options are available under a heading of [cciipx-base] in the CCI.INI file.

CCI.INI can be located in a number of locations for testing and deployment. On Windows systems of all types the Windows root directory is a good location as it is visible from all applications. There may be configuration sections for more than one CCI protocol module in any CCI.INI file.

If you only want to affect the behavior of a single application, rather than affecting every application on the system, put the CCI.INI file (containing the CCIIPX entries for this application) in the current directory - the directory from where the application is being run.

What form do CCIIPX CCI.INI options take?

A sample CCIIPX section of a CCI.INI file could look like:-

[cciipx-base] 
 REPORT_CONNTYPES=n 
 CRC_SEND=n 
 CRC_FORCE_RECV=n
 CRC_REPORT_FAILS=n
 CRC_RETRY=y
 MAX_PKT_SIZE=17872

Acceptable entries for yes/no options are, "Y","y","YES" or "yes", and "N","n","NO", or "no". Mixed case words such as "Yes" are NOT accepted and default settings will be used if their use is attempted. Numeric values must always be entered in decimal format, use of HEX and OCTAL values is not supported and will lead to unpredictable results. Any unwanted entries in the CCI.INI file can be commented out using ";" as the first character of the line.

3.3 Available CCI.INI Options for CCIIPX

3.3.1 Basic CCI.INI Options for CCIIPX

REPORT_CONNTYPES, default setting "n".
If the application calling CCIIPX is a Console type application running on Windows 95 or Windows NT, a display will appear on the screen at the connection of a client to a server giving details of the type of connection that was established. These details include the protocol revision number (200, 201 or 202) and the maximum packet size that can be used to transmit data on the new session.

If the application calling CCIIPX is not a Console type application running on one of the systems listed above, the output is lost.

An example of output for an Ethernet based connection which doesn't use CRC checks is
```
"Con_Accepted: CRC_NO_SEND - v201 client, max pkt 1394 bytes"
```
CRC_SEND, default setting "n"
Create a Cyclic Redundancy Check checksum and include this in outgoing packets, this process slows down data transmission but ensures greater data integrity on links where corruption is suspected. Connections with CRC checking switched on appear as protocol versions 200 and 202 .
CRC_FORCE_RECV, default setting "n".
Some servers will automatically discard CRC information from clients to save time, use of this flag will force the receiving servers to create a session which always uses the CRC information when sent from this client machine. Links with this flag set are seen as protocol type 202.

NetWare Client v4.0 for NT has a inherent data integrity problem, when this client is installed CCIIPX will detect this and will always include CRC data in sessions created from these machines, CCIIPX clients on these machines will always force any server accepting their connections to use this CRC information, hence these clients will always be of protocol type 202.
CRC_REPORT_FAILS, default setting "n".
This is a debugging setting, which can be used to display a notification message whenever a CRC check fails. This setting is obviously redundant in the default installations which do not utilize CRC checking at all
CRC_RETRY, default setting "y".
This is a debugging setting, which allows a system setup to use CRC checking to behave as if no CRC checking were being performed. Used in conjunction with "CRC_REPORT_FAILS=y" it can confirm a data integrity error on a link and appropriate action can be taken on the client and server systems to enable CRC checking to always preserve data, at the expense of speed on the links.
MAX_PKT_SIZE, default setting "17872".
This option defines in bytes the maximum size of a data packet that can be used by CCIIPX. It will not always be possible to connect two machines at this size of packet, but negotiation to determine the largest possible packet to transmit and receive takes place at the initialization of a new session, so the largest possible packet that can be carried on the intervening link between two machines, up to this limit, will be used whenever possible.

3.3.2 Advanced CCI.INI Options for CCIIPX

SAP_OBJECT_TYPE, default setting "2088".
MERANT has registered service type 0x828 for CCI use, if users wish to utilize another service type in the SAP registrations they may alter this setting to do this. Users MUST remember to always use the new setting on ALL systems which require access to these re-assigned services. Since no other service type setting is registered with Novell for MERANT CCI, MERANT cannot be responsible for any clashes with other installed services which my also be SAPing with the newly associated service type.
KA_PERIOD, default setting "27".
This is the time period, in whole seconds, between attempts to confirm the continued existence of the remote end of a quiescent connection.
See KA_RETRIES for more details.
KA_RETRIES, default setting "3".
This is the number of retried attempts to confirm the continued existence of the remote end of a quiescent connection that are allowed to be missed before the remote end of the connection is declared lost.

See KA_PERIOD for details as to the inter-attempt time period.

Users may alter this setting to adjust the time-out of a connection and hence alter the time of detection of a dead connection. On WAN and dial-up links this period may be lengthened to accommodate the delays imposed in these architectures.
MAX_ASYNC_SEND_PAUSE, default setting "400".
Maximum time in milliseconds between successive sends if no ACK has been received from the receiving end during an attempt to send a buffer. After this time another attempt will be made to send a reminder packet to the receiver.
This is a very advanced setting which should only be used upon advisement from tech support, it is used to tune the system to avoid retries on already congested networks.

3.4 Application Configuration

CCIIPX Client/Server applications use the CCI Server Name and Machine Name parameters to enable the CCI Client to specify the CCI Server with which to communicate.

The CCI Server identifies itself on the network by using the Server Name parameter. The CCI Client specifies the CCI Server using the Server Name. Additionally, if it only wants to find this Server running on a particular machine in the network, it needs to specify the Machine Name parameter.

3.4.1 CCIIPX Server Name

Both CCI server and CCI client applications need to have a Server Name specified: server applications need to register themselves as available under this name (or what fixed port to use); and clients need to specify which server they wish to contact.

This can be any valid alphanumeric string (up to 47 characters in length). Strings must be terminated with either a space (" ") or a NULL (binary zero) byte. Names presented with a length greater than this limit will be rejected with a bad parameter message, to avoid the possibility of a truncated name allowing connection of a client to an unwanted service.

3.4.2 CCIIPX Machine Name

This is a parameter that only needs to be specified by CCI client applications.

There are two aspects to the use of Machine Name

Clients for later versions of the old 16-bit broadcast based CCIIPX and the new CCIIPX for 32-bit Windows installations support the use of a 'Machine Name' parameter when calling CCI Client initialization functions.
The broadcast based CCIIPX modules support the string format:
- '<network>.<node>.<port>' - where the service port address is known.
- '<network>.<node>' - where the service port address is unknown.
For example, "33c251.1" for a NetWare Server based CCIIX32.NLM hosted service, where the NetWare Servers internal network number is "33c251" and the logical "node" address for the server is "1".

The new 32-bit Windows hosted CCIIPX modules support the use of 'machinename' in exactly the same manner as the older broadcast based CCIIPX modules, however the SAP based module also support the use of ',' as the name element separators

For example, "33c251,1" for the NetWare Server in the example above.
The 32-bit Windows hosted CCIIPX modules use the Novell NetWare Service Advertising Protocol (SAP) to detect the presence of CCIIPX services, without the direct need for 'machinename' information.
The Service location detection is done by querying the contents of the NetWare Server which the client is attached to at the time. However if a large number of connections/disconnections are to be made with the same service, this SAP look-up can take up an appreciable amount of the overall time spent in using a connection.

If the application using CCI supports this style of access, one such application is AAI, it is possible to avoid the requirement to search the SAP information on the connected NetWare Server and make the connection directly and thus speed up the connection time.

This is done as follows:-

Set 'Machine Name' to "FFFFFFFF,FFFFFFFFFFFF,FFFF"

The contents of the data area which holds this set of values will be over-written with the correct location of the server on the first successful connection attempt. If the same information is then passed back to the CCI Client connection call on the next connection/disconnection loop by the application, the CCI Client connection call will attempt to connect directly to this location, and avoid using the NetWare Servers SAP table completely.

If three attempts to connect using this method are ignored (this takes 12 seconds during CCI Client connection execution time), the client will then use the NetWare Server's SAP tables and attempt to locate the service in the usual fashion. This technique provides a backup connection path, should the location information in the 'Machine Name' area become stale.

Please note: the use of "FFFFFFFF" parameters in any other format or combination with other groups of numbers is invalid, and will result in a parameter rejection message being returned by CCI.

CCIAPPC Configuration

CCINETB Configuration