VLM v1.20 VLM v1.20 SHIPS WITH NETWARE 4.10 Product Requirements The NetWare DOS Requester (VLMs) is the requester component of the NetWare 16-bit Client for DOS and MS Windows. VLM is the primary technology that provides access to NetWare 4.x servers from the DOS environment. A set of goals and features was established for the 1.20 version of this product prior to its development. These goals and features included: Improve performance through the optimization of current algorithms. Increase reliability through extensive testing with 3rd party applications and through extensive Beta testing. Provide hooks and features to enable the integration of mobile products. Provide capability to load VLMs without active network connection in support of mobile products. Clean up existing critical discrepancies in the product. Provide support for multiple-connection auto-reconnect. Ability to load REDIR.VLM into low memory made available in order to improve I/O performance. Provide better support for EOJ, Lock Retries, and other NET.CFG parameters not fully handled. Implement the Force First Network Drive parameter for the NET.CFG. Handle any outstanding issues to ensure the successful deployment of the VLMs in Japan with the release of NetWare 3.12J and PNW J. All the goals and requirements for the v1.20 VLMs were general. The primary focus was to provide a stable VLM client. Customer concerns regarding size and performance were addressed within the constraints of the current design. New Features The new features and enhancements provided with the v1.20 VLMs provide the customer with a tested, stable platform. The primary goal of the v1.20 VLMs was to provide a highly reliable DOS client for release with the NetWare 4.10 product. Additional features and enhancements were included to support other NetWare products, and to meet customer needs. Feature enhancements made to the v1.20 VLMs which concentrate on new NET.CFG parameters include: Load Low REDIR = Off, On (default Off) This parameter is provided to improve small I/O performance. There is an increase of conventional memory usage in exchange for the increased performance. Loading REDIR.NLM low uses additonal conventional memory. Load Low FIO = Off, On (default Off) This parameter is provided to provide additional tuning in favor of performance over size. By loading fio low additional conventional memory is used. Load Low NETX = Off, On (default Off) This parameter is provided to provide additional tuning in favor of performance over size. By loading netx low additional conventional memory is used. Force First NetWork Drive = Off, On (default Off) This parameter is provided to force the re- establishment of the first network drive when logging out from any other network drive. Please note that the connection to the first network drive is based upon the default drive connection at the time the logout was performed. LIP Start Size = 0; 576-65535 (0=off) This parameter is provided to improve performance, at connect time, across multiple hop routes when one segment of the network has a smaller packet size than the local routes, but a larger packet size than the minimum of 576 bytes. This new algorithm dramatically improves connect time utilization of the wire. The following scenerio is provided to demonstrate the changes in the LIP negotiation algorithm: A given network consisting of 4KB token ring segments, capable of handling 1500 byte packets, and positioned at two distant locations are connected by a WAN. Large Internet Packets must be used to maximize the throughput of the link. Both scenarios, with and without Lip Start Size, are described below to demonstrate the new algorithm. Before: Prior to implementing this parameter, the LIP negotiation algorithm consumed the link. The server and the client are both on a 4KB capable segment. During the initial negotiation sequence, the client negotiates an initial packet size of 4KB. The server responded to the request with an acceptance of the 4KB packet. The initial LIP negotiate sequence sends out three 4KB LIP echo packets to the server. No response is received, so another three packets are sent to the server, this time at 576 bytes, to ensure that the route is valid. Three echos packets are received back from the server. A binary search is then performed to identify the optimal LIP size for the given route. The mid between 576 bytes and 4KB is then sent out in a group of three to the server. If that is not successful, then the mid between that number and 576 bytes is attempted. If that works, the binary search continues until the maximum bound is successful. Over 60KB of data is sent across the WAN link to negotiate the WAN link. The time to establish the link can also be painfully slow across the WAN. Now: The algorithm has been modified in several ways. Primarily the administrator can specify the initial LIP negotiate size. If LIP Start Size = 1500 was set in this example, the optimal configuration for the link can be quickly established with minimal data flow across the WAN. In this instance, one 1500 byte packet would be sent to the server. The server would echo the 1500 byte packet back to the client. The client would then send a 1600 byte packet (1500 bytes + 100 bytes) to the server. This packet would not echo back to the client. The addition of the 100 bytes to the packet is used to determine if the server is local, or if it is being sent across the WAN. If the server is local, the standard negotiation would proceed, the following 4KB packet would be successful. In this case, the echo packet would not be returned. Only one packet was sent during the initial echo request. To determine if the link is unreliable, an additional two packets of 1600 bytes each are sent to the server. No echo is received back from the server. The optimal size is then set at 1500 bytes for the link. A total of 3KB is sent across the WAN link. A savings of 60KB is realized, as is an increase in performance. Confirm Critical Error Action = On, Off (def On) This parameter is used to turn off the critical action popup in MS Windows. This dialog is popped up prior to tearing down a lost connection while in Windows, providing the user with the choice to attempt retry (and possible auto reconnect) of the last request. This parameter ensures that a critical error message is provided in the Windows environment. Many applications turn off the Windows critical error handling mechanism. This forces an automatic failure/cancel, thus otherwise overriding any chance for the user to retry the connection before it is torn down. Read Only Compatibility = Off, On (default Off) This parameter is not new. It was set to On with the last major release of the product. Because this caused problems with many applications, this parameter's default is now set to Off. Lock Delay and Lock Retry. These two parameters were not fully implemented in past releases. They have been implemented and tested for this release. New v1.20 VLM features include: If the Node address is set to -1, the client does not require the presence of a server to complete loading. This capability is provided to enable the mobile networking products. This feature works in conjunction with the new IPXODI.COM which provides the ability to set the node address to the -1 value. You use this feature with the new IPXODI.COM, which allows you to set the node address to the -1 value by placing twelve Fs in the node address parameter in the NET.CFG file under the Link Driver heading: Link Driver drivername node address FFFFFFFFFFFF The LIP negotiation algorithm has been changed to improve negotiation speed and decrease throughput. Groups of three packets had been previously used in the negotiation of the maximal LIP size. Two states have been defined to reduce the number of packets sent across the network. The connection is initially placed into a "trusted state." When in this state, one packet is sent to the server with one accompanying echo reply. If a reply is not received from the server when expected, the client is placed into a "non-trusted state." In this state, groups of two LIP echo packets are sent from the client. This packet count is less than the three packets previously used. This generally results in faster negotiation of LIP, and fewer packets going across the wire. A hook into the INT 24 handler has been provided to enable link handling of mobile products. This permits mobile products to bring down any dormant connections, then reestablish them without causing critical network errors. The NUL device support has been implemented into the V1.20 VLMs. This enables such command line commands as ‘If exists NetWare path\NUL ....’ The VLMs have been optimized to work cleanly with multiple redirectors. Some of the specific redirectors tested include the redirectors from 3COM, Novell NFS Client, and DEC Pathworks. Additional video modes are supported for incoming messages. A sideband network error reporting mechanism has been implemented where appropriate to ensure that network errors are not translated into DOS errors. The auto retry character has been language-enabled. This permits the Auto Retry feature to work in other languages where an ‘R’ does not signify retry. Support has been added to enable the Auto Retry feature under MS Windows. The internal notify code has been optimized to the load time performance of the VLMs, and to improve performance during login. Product Limitations There are several limitations to the v1.20 VLMs due to architectural limitations. These limitations are being addressed in the design of the next release of the VLM. The v1.20 VLM limitations include: Maximum path length of 67 bytes. Previously this was a 128 byte path length limitation. Due to the redirector implementation of the v1.20 VLMs this path length cannot be enhanced because of the limitations of DOS. In many cases; however, path length limitations can be overcome by map rooting into the directory tree. Full command-line Device redirection, where a NetWare path is used (i.e. F:\..\AUX), cannot be provided due to limitations imposed by DOS. The NUL device support is the only device that has been implemented. The VLMs do not match the transaction-speed performance of NETX. Where NETX can perform 12 transactions per second, the VLMs can perform only 11 transactions per second. This performance decrease is due to the transition through DOS for each request/reply. The transaction metrics are based upon a Clipper application designed to perform small record transactions. However, the VLMs meet and out perform NETX in mid-and large- sized reads and writes. The VLMs are not able to operate in either the private or the global DOS sessions of NT and OS/2. These DOS environments do not provide the back-end INT 2F support upon which the V1.20 VLMs are built. Major Fixes The major problems fixed in the V1.20 VLMs are listed below. These are generally problems for which we received a large number of complaints, or which we identified as being highly visible with a high impact upon the customer. Fixes to the VLMs, NetWare Libraries, and Utilities. Fixes were coordinated to cleanup connection-related problems. Problems resolved included hard counts that did not accurately increment and decrement, leaving connections in unpredictable states under specific conditions, and licensed connections at the server that were being consumed when they should not have been. Packet burst code was cleaned up for special-case scenarios where fragments could be lost. Also fixed were problems that could present themselves in WAN environments. EOJ code was fixed to work properly under all conditions. Problems related to ensuring the use of proper task IDs for the VLMs were fixed, along with problems related to ensuring proper interaction with other tasks. COMSPEC code was modified to handle command processors other than COMMAND.COM. The behavior of the temp drive and temp directory handle support (Int 21 E2) was also corrected. The "Qualify" code paths were modified to ensure proper operation, and to improve performance. Code associated with the NET.CFG "Search Mode" parameter was fixed to ensure proper operation. Auto-reconnect code path was changed to support simultaneous auto reconnection of multiple connections. The cache buffer segment overflow scenario was corrected. Typically, related problems were manifested when using large token ring packets where the NET.CFG "Cache Buffers" parameter needed to be backed off to fit within the memory available to cache. The IPX signature string was added next to the INT 7A vector address to emulate NETX behavior. Compatibility between NETX and DOS return code was improved. Errors related to multiple record lock attempts involving three or more stations were corrected. Problems with use of multiple redirectors, including MSCDEX, were corrected. NUL device redirection and directory detection on a network drive fixes were implemented. READ ONLY COMPATIBILITY now defaults to OFF instead of ON to match that of NETX. Anomalies with batch files involving LOGIN.EXE were eliminated. (Note, certain caveats apply here.) Network path parsing was improved to act more like that of DOS. Packet timing algorithm problems were corrected to better support slow WAN links. Packet signature problems related to working over WANs while bursting were corrected. Related negotiation issues were corrected to enforced checksumming and packet signatures at the client when requested. Short-lived socket support has been disabled under Windows per the MS Windows SDK. Support for properly handling broadcasts when VLMs are loaded in multiple VMs under Windows was corrected. Int 24 error string problem--where garbage was displayed in certain circumstances--has been corrected. Invalid message formatting caused by the use of an incorrect message file has been eliminated through implementation of message file version control. Renaming files across servers is now properly detected, and the correct error is reported. The old library function "GetPrimaryID()" call has been fixed, as it could have caused problems with specific login and logout sequences. Improperly formatted or invalid file name information on Qualify remote file name calls is now corrected. Both the Set Task Mode and Get Task Mode calls were corrected to ensure that the bit is set and placed in the correct segment of memory. Tidbits For faster performance in XMS memory, consider loading REDIR.VLM into low memory using the new NET.CFG parameter. Performance will then be at a level similar to that of loading the entire VLMs in conventional memory, but memory cost will be substantially lower. Consider reducing the memory footprint by: * Excluding PRINT.VLM if no printing is desired. * Lowering the number of Network Printers if LPT1 is the only captured port. * Reducing the number of connections if the client is on a small network. * Excluding SECURITY.VLM if packet signing is not required. * Excluding those NetWare Protocol modules which are not part of your network (i.e., BIND.VLM for bindery-based servers, NDS.VLM for Directory Services-based servers, and PNW.VLM for Personal NetWare servers). Develop an understanding of who is using the Upper Memory blcok (UMB), and how it is being used. This is one of the best ways to improve memory utilization. VLMs always try to maximize the use of the UMB, but will be unsuccessful if other TSR's have already used or fragmented the memory. Loading these TSR's after loading VLMs may allow the VLMs to maximize the memory use of the UMB area. VLMs need more memory at load time than after load time, another good reason to load those TSR's which use the UMB area after loading VLMs. Note: More information on memory utilization and optimization for the DOS Requester can be found in the May 1994 and June 1994 issues of Novell Application Notes. Known Problems ** Multitaskers which do not generate unique PSP's across VM's (ie. MS Windows defaults to generating unique PSP's, system.ini parameter uniqueDOSpsp=TRUE) may see a problem in CONN.VLM, if the following circumstances are all present: * Two task are running in different VM's and are assigned the same PSP number. * One task terminates while the other is still active. NOTE: This may cause an endless loop hang depending on the task allocation order in CONN, and the termination order of the tasks. ** TSR's which do not use the Idle interrupt (Int28), and which base their entire re-entrancy availability for NetWare Int21's (B6h and up) on the SDA's InDOSFlag may see some re-entrancy problems. The problem is the result of reentering a NetWare Int21 based on the InDOSFlag. ** Certain MLIDs (Multiple Link Interface Drivers) may show a problem with IPXODI. The issue is with certain NCP's which return more data than has been provided in the reply buffer. You may see a timeout / Network error when encountering this scenario, although it is very uncommon. If you do encounter this error, you can fix the problem by running the latest IPXODI. ** As mentioned in the Limitations section, some DOS device support may differ slightly from local DOS behavior. For example, if an application opens device F:\USER\TIM\PRN for printing, the DOS Requester passes the request on to DOS. DOS then fails the request because it uses a network path. ** AutoReconnect will not work with Signing enabled on a NDS connection (4.x server). ** AutoReconnect will not work with 3.x servers if the LOGIN.EXE is not a 4.x version of LOGIN. ** The default login drive is always map rooted. For example, if your first Network Drive is F, after loading the VLMs, drive F will show as a SYS:LOGIN root mapping (F:>, not F:>SYS:LOGIN). ** If a print job is deleted while in an ADDING state, the client terminates the capture because it receives a file IO error. This is the same behavior as NETX except that no message is printed indicating the failure and possibility of a full disk. This lack of a message will be remedied in the future. ** The DOS Requester relies more on the DOS environment PATH variable for its Search drive information than did the old shell. For this reason, handling of the PATH needs to be watched closer than with the SHELL. ** Error mode still has task-based issues. For instance, Task 1 in VM 1, which sets the error mode to 2, may not see the proper error mode behavior if Task 2 in VM 2 sets the error mode back to 0. ** The DEC Pathworks product can use the standard or enhanced MS Redirector in parallel with the VLMs. The MS Redirector has a file problem with file execution on RO executables. Microsoft is reported to be aware of this problem and working on it. You can avoid this problem by setting the file attributes to RW.