New Features:

Default Page Processing

You can now specify, on a directory by directory basis, a single HTML document that will always be called in leu of the page specified in the URL.  This allows you to write a single active page that will handle all inbound page requests.  The intent here is to allow you to write your own hook to pre-process the request and then pass control back to the web server with a call to PLW.PAGE.

The SAMPLE.WEB file includes one of these pages _DEFAULT.HTM

Global Error Pages

A new set of error page templates are now stored globally in WWW.CTRL,LOCAL.PAGES.  These pages are used to process web error pages.

Enhanced Error Pages

You can now specify, on a directory by directory basis, a single HTML document that will be invoked when any HTTP error is encountered. This allows more elaborate error pages to be generated including logos and additional information.

---

Platform Notes:

D³/NT

• PicLan-IP requires that all Pick/BASIC code is compiled with the (O option to enable Flash/BASIC.  This includes any CALLed subroutines. The PicLan-IP PC verb will compile with the (O option by default.
• PicLan-IP is setup to use DLL number 9.  This is currently hard-coded within PicLan.

---

Bug Fixes

Bugs fixed in 2.0.0(107)

• Inbound TELNET functions with AP/Pro were not correctly "quoting" CR characters as CR:NULL in the TELNET stream.
• CACHE-WEB was manipulating network connections unnecessarily.
• The PicLan-IP thread processes will no longer exit if a specified web content file or DSG is not found.  An error will be displayed and the rest of the web server will continue to operate.

Bugs fixed in 2.0.0(108)

• System crash when AP/Pro is configured for inbound TELNET.
• TELNET performance problems.
• CACHE-WEB now works with HOST type directories

Bugs fixed in 2.0.0(109)

• TCP/IP Protocol Bug (native hosts)
Several problems with TCP/IP packet retry and timeout logic were corrected and packet-retry logic has been tuned to improve performance.  This primarily impacts TELNET users.

Bugs fixed in 2.0.0(126)

• State number zero has been disallowed.
The low-level driver will no longer allocate connection number zero. This eliminates a bunch of standed state conditions.

---

Performance Tuning

Performance tuning in 2.0.0(108)

• PLIP-MONITOR now communicates with thread processes via the driver instead of a shared file.  This greatly reduces lock contention issues.
• WinNT/Win95 buffering has been re-worked to use memory dynamically and to greatly increase the size of inbound and outbound connection buffers. This yields a 5x performance improvement when serving large pages.

---

Limitations, Bugs, Quirks:

Last updated with PicLan-IP build 2.0.0(126)

• The driver is partially using memory statically.
• Native Hosts (AP/Pro, Mentor PRO, Sequoia PRO)
• About 1 megabyte of memory is required for each 100 connection blocks
• The outbound burst window is dynamic from 2K to 64K
• The maximum inbound burst window is 2K
• The driver supports at most 4096 connection control blocks
• Running out of connection blocks is untested and may be unpleasant
• 4096 connection blocks require more than 32 Megabytes of memory
• Windows 95/NT Hosts (D³/NT, mv*Base)
• 4096 connection control blocks are always allocated.
• Connection buffers are allocated dynamically and may grow to be quite large (depending on your web content)
• Make sure your Windows swap file is large enough.
• Unix (D³/Linux)
• 1000 connection blocks are always allocated.
• Connection buffers are allocated dynamically and may grow to be quite large (depending on your web content)
• Make sure your Unix swap partition is large enough.
• The driver has a variable drop-dead date that is set when the authorization code is entered.
• If the release is run without a valid authorization code, web functions will operate at 2K/second without bursting.  All other PicLan-IP functions will be disabled.
• Email subsystems
• Email functions are now running very smoothly.
• Main messages above 5 Megabytes in size can seriously slow the mail server
• Do not test email functions with large messages on systems without an abundance of available disk space (at least 10 times as much available disk space as message size)
• Workspace limitations
• The software relies on the underlying MultiValue implementations being able to handle and manipulate very large string, sometimes several megabytes or more in length.
• Do not test functions with large document size (web, email, graphics, etc.) unless you system has a lot of available overflow space
• AP/Pro users are encouraged to enlarge the overflow reserve pool with:

SET-OVF-RESERVE 50000

• Performance with "dumb" disk drives can degrade because of a tendency of AP/Pro to flush disk aggressively.
• Caching disk controllers and/or drives should help this.
• Halt tolerance also can degrade perforamance.

• System instability has been noted with the boot IDE bios drivers. Loading 32-bit IDE drivers appears to correct the problem.
• This problem appears to be eliminated as of PicLan v 2.0.0.23 and PicLan-IP v 2.0.0(126).
• Mentor PRO 4.0, 4.1, and 5.0 have all been tested.
• Mentor PRO (and mv*Base) appear to have an unusual behaviour when working with large strings.  Run-time BASIC does not appear to be performance "Garbage Collection" when it should and manipulating large strings can result in more system overflow space in use than would be expected. The end-result of this is:
• Performance is degraded because more dirty frames are created.
• You should take care not to run the system out of disk space.

• Sequoia PRO does not always seem to cleanup workspace allocations when a large number of BASIC compiles execute in sequence.  With Sequoia PRO 2.4.3, this can sometimes lead to system aborts (FLZ, etc.) when the web server is building active pages on the fly or when the CACHE-WEB command is used.  Sequoia PRO 2.4.5 has not been tested yet and this problem does not always seem to happen.
• Sequoia PRO PicLan 2.0.0.13 has only been tested on very limited hardware. Particularily, the PCI network driver is present but has not been run as of this documentation.  If you are running Sequoia PRO, it is your responsibility to test for stability on your hardware.

Web server restarts have been smoothed out.  You should always use PLIP-START and PLIP-STOP as opposed to using the manual PLW-MAIN program.

General performance notes

• When doing web development with embedded BASIC code, the most time consuming operating is the building, parsing, and compiling of generated code for HTML pages that contain executable BASIC. With Mentor PRO 4.x on a Pentium 150, this usually takes only 2 to 5 seconds. On a slow 486 running AP/Pro, this process can take over a minute. This overhead only occurs the first time that a web page is touched for the first time, so a production system should actually do better.
• If you value your programmer's productivity, give them a reasonably fast system.
• A pentium or better appears to be adequate
• 8 megabytes of memory is adequate unless you are testing large documents when 16 megabytes appears better
• If you are running Windows NT with mv*Base or D³/NT, you should consider a development system with 32 to 64 Megabytes of memory. This is not because of the memory usage of mv*Base or PicLan-IP, but because of the memory usage of NetScape/Internet Explorer plus your web editor, all running on the same box.
• If you are testing large numbers of concurrent connection, you will need even more memory (possibly much more)
While specific performance comparisons with NT and Unix web servers have not been run, PicLan-IP appears to be "fast enough" for are large number of public sites and applications, especially when active content is in use.