|
|
PicLan-IP version 2.0.0.135 is a major release that addresses a number of areas. This document describes chages in version 2.0.0.135.
Due to the nature of some of the changes to this release, care should be excercised when loading this release onto production servers. Testing is limited to a small number of systems and not all scenarios have been tested.
Mentor PRO
Reports of system stability issues have been reported with both PicLan and PicLan-IP running on Mentor PRO. The following symptoms have been noted:
- System hangs
- Reports IDE hard disk errors
- Corruption of the console video display
- Loss of the console cursor
These problems tend to be dependent on both system and network activity. In addition, these issues seem to be much more prevelent on systems not loading an installable disk driver (either IDE or SCSI).
Examination of these scenarios yielded the likelyhood of a stack overflow. Stack overflows are situations where a driver-level software routine uses more system stack space than is available. On Mentor PRO, the system stack space starts at 0x00002000 and counts down until low-level tables are overwritten. This makes the actual usable stack space only about 4K bytes in length. Another characteristic of stack space usage is that drivers that handle system interrupts will have the potential of using additive amounts of stack space.
It appears that PicLan-IP would actually require most of the 4K of total stack in order to process TCP/IP protocol operations. Add this on top of other system drivers such as the BIOS disk handler and the stack would begin to push into system control areas. On some systems this would cause "phantom" hard disk errors by overwriting the hard disk parameter scratch area that is used by some BIOS manufacturers. Other system could crash all together or have other corruptions.
This new build of PicLan-IP signifigantly reduces stack usage by saving and restoring the system stack during the PicLan-IP processing. This not only lowers the stack usage within the PicLan-IP driver, but also lowers overall stack usage further if Piclan-IP happened to interrupt another driver mid-stream. Testing shows that the new driver runs reliably even on systems that do not load any hard disk driver (and are thus using the default boot BIOS calls). Previously, even IPX PicLan would not run consistently on heavily loaded systems in this environment.
All Native Platforms - Secondary Memory Allocation
When you execute the PLIP-INIT command, a number of elements are initialized. In addition, additional buffer space for network control blocks and buffers are allocated. This "secondary memory allocation" takes place in 1 Megabyte maximum blocks. Several system appear to be having stability issues which may have to do with these secondary allocations. This build makes defensive changes to the memory allocation logic that PicLan-IP uses in an attempt to alleviate these problems. There are some issues that you should note:
- Most systems do not experience these problems
- AP/Pro Systems are the most pronounced, although this has been observed on a single Mentor PRO system.
- The changes made are defensive in nature
- The actual low-level driver and TCP/IP protocol stacks are not modified by this change.
- Only the amount of memory allocated and the position of the driver buffer space within the allocated region have been changed by this defensive modification.
On AP/Pro systems this problem would often manifest itself as a system ABS corruption. On other systems the result would often be a system hang.
The defensive workaround for this issue is to have PicLan-IP allocation a 64K buffer space on each side of each seconary memory allocation. The presence of this buffer space seems to keep PicLan-IP from overwriting Pick buffers or Pick from overwriting PicLan-IP buffers (it is not currently known which scenario is more accurate description of the actual issues). 64K is probably more than is needed, but seemed like a good starting point.
The only downside of this defensive workaround is that 128K of system memory is wasted for each megabyte block that PicLan-IP allocations. For most systems, there are only one or two secondary allocation blocks, so this additional space should not be signifigant. On systems setting the CONN= parameter in the CONFIG item to a high value, it is possible that this change may use several megabytes of system memory. Regardless, these systems already have >30 Meg of system memory allocated to PicLan-IP.
This scenario is still be investigated. Expect additional tuning of the workaround that is included in this release. You should note that this defensive workaround is being included because several sites are experiencing specific stability issues and the nature of the code change is best described as "safe" or "benign".
The scenario involved here appears to be different that just loading stock IPX PicLan. This is possibily due to the manner in which PicLan loads it's driver where there is an inherent 0-62K buffer area around the driver (this allows the driver to load on a 64K boundary which makes our debugging efforts easier).
Test of this workaround on in-house systems at Modular Software is complete for both AP/Pro and Mentor PRO. Both platforms have been stress tested with simulator programs that have literally pumped gigabytes of data through the HTTP engine. Other than an occasional network adapter hardware overrun, all test ran with a 100% success rate (it should be noted that TCP/IP stack overruns caused by network card buffer overruns are inherent in the ethernet hardware itself and exist on all TCP/IP hosts including NT and Unix).
State Security
The session ID number used to manage execution threads has been expanded. Previously, a simple integer field was used as a session ID. This would allow a user to guess at an active session ID and thus gain access to other sessions information. This build changes the session ID to include not only an integer value, but also a 10-digit random number. This makes the process of guessing another valid session ID nearly impossible.
Refresh Bug
A bug dealing with screen refreshes corrupting session workspace was fixed. This would appear if a user experienced a page "refresh" operation because of pressing the "back" button or double-posting a page.
_INCLUDE Statement
The _INCLUDE statement now functions.
The HTTP Server has been enhanced to cleanup and timeout connections that have invalid source formats.
Syntax Enhancements
The syntax for the PLZ command has been enhanced to allow for easier compiler operations. The FILE|HOST|DSG parameter is now optional. Also, PLZ will now operate with multiple items using either an '*' for all items or operating with active select lists.
The use of FILE|HOST|DSG is also optional in the _PAGE statement.
_BASE Extension
In order to make it easier to manage application source code, you can now include a statement _BASE within your project. If this statement is present, a base path will be setup for subsequent _PAGE statements. For example, the following two programs will create identical applications:
_PROGRAM APP.OBJ PGM1 * _PAGE APP.HTM PAGE1.HTM ... _PROGRAM APP.BOJ PGM1 * _BASE APP.HTM _PAGE PAGE1.HTM ...
The intent here is that you can include a single _BASE command in a common _INCLUDE module. This sets the location for here HTML pages are to be retrieved from. Subsequent _PAGE commands then only need to state the actual page name and not the path to look in. Then, if you wish to move your HTML source pages to a new location, you can do so while only needing to change a single statement in your mv/WEB application.
The low-level PicLan-IP driver has been enhanced to handle more PicLan-IP connection timeout issues without requiring as much intervention from the high-level PicLan-IP BASIC server. The intent here is to lower the overhead of managing connection timeouts and to improve the reliability of these timeouts. This logic changes the default PicLan-IP behavior that all server-side connection have "sanity" timeouts so that connections will not get stranded indefinately.
This new code logic is a quite sweeping change to the structure of the PicLan-IP server. As such, it is suspected that some timeout related issues may be encountered in this release.
|
|