If I'm retracing ground already covered, please excuse me.

Having just spent much of a weekend grubbing through Interserver
trying it isolate a problem misdiagnosed as a JVM bug (in fact
a URL typo), I noticed a number of things:

1. If interserver were multi-threaded it would be faster,
less resource intensive, and much easier to debug. Since
Java itself requires threading, I can't imagine any LANs
requiring an interserver who don't have a machine with
a threading package. The threading semantics of Win32
and Posix threads are so close that common source is
trivial.

2. Interclient and interserver set the TCP connection to
NO_DELAY, which results in lots of little packets and
lots of expensive OS calls. Dumping NODELAY mode and
doing a simple "flush" on the "get response" calls is
much more efficient.

3. If interserver is run on NT with a name other than
"interserver" or from a directory other than the
one containing the executable image, the CreateProcess
interserver uses to emulator a "fork" picks up the
wrong image or none at all without a diagnostic. There
are many ways to fix this, but the right answer is to
dump fork/CreateProcess in favor of threads.


Jim Starkey