Mail Archives: opendos/1997/12/16/17:41:24
As far as INTERSVR and serial links are concerned: PPP isn't as
efficient as a well-designed system optimised for the medium, so it
isn't an ideal alternative (yet it is very attractive for its
flexibility). For that matter FILELINK isn't perfect either, but I
wonder if there could be a replacement that gives the best of both
worlds - and gets us InterSvr compatibility at the same time!
I'm not sure if it is feasible, but...
Suppose there is a replacement server for FILELINK that uses two layers
- a command you run (that knows little of the protocols underneath)
plus a resident part with (DPMS?) modules/overlays for serving INTERLNK,
old FILELINK, Kermit, LapLink, PPP (etc) clients. When no connection
is established it would load a "listenning" module, after that it would
replace that with a module for the protocol detected.
Ideally it would become part of the ODI stack, with one module that
does the job of coms port PPP/SLIP MLID (& dialer?) plus an alternative
to SERVER.EXE that can run as well as the PNW stuff. If configured
with the server, another PC could access files using FileLink or
whatever; otherwise it would require the local PC to put/get files from
the second PC. This would mean a PC with a reasonable amount of RAM
could act as a non-decicated server for whatever MSDOS or OpenDOS
systems that are plugged into the serial port (having the server go to
top priority when contact is initiated is better than having the server
take over the machine all the time the server is running). The
features of FileLink-type contact are much less than Personal Netware
(hence less RAM requirements, I hope). It could perhaps also allow an
OpenDOS machine to act as a bridge so you could access etherneted
resources when plugging serial-only computers (such as laptops) into
this system from time to time without having to install network cards
in them all.
Transparent File Access Ftp-like put/get
/ | \ /
/ NETX or VLM ViewMax New FileLink
XFS | \ /
| IPXODI SERVER New Simple API
ODIPKT | | / |
\ | | NETBIOS |
\_____|__________|______/ |
/ \ |
/ \ |
e.g. NE2000 \ |
\ COMBINED PPP/FILELINK HANDLER
\ /
LSL.COM
I imagine the "New Simple API" would consist of operations such as
"open a connection" "get a file (to local disk or RAM)", "put a file
(from local disk or RAM)", "list files" and not much more. These could
all be translated into equivalent FileLink, InterLnk, Kermit, Zmodem,
or even ftp, tftp, unzip (etc) operations. If the Combined PPP/FileLink
handler responds to the NetBIOS "start session with NCB_NAME" command
and passes on unsuccessful call attempts to any pre-existing NetBios
handler it would be easy to create a simple library of calls to include
in programs like a new FileLink or new ViewMAX that translates requests
to open folders/view directories into simple NetBIOS commands, then
have our handler implement just enough to translate into FileLink (etc)
operations. This would allow the maximum flexibility, and keep the RAM
requirements of the server & applications that use the API relatively low.
The alternative would be to make the resident driver translate normal
(LFN perhaps) system calls into operations FileLink, InterSvr, Kermit
etc can understand, which is likely to increase the complexity and
hence RAM.
Of course I might be totally wrong, but what do others think? If
FileLink needs a major overhaul anyway (which I think it does), why not
take the opportunity to make it much better? So long as it doesn't take
up a lot of RAM while not being used, just about anything is better
than the present systems in MSDOS and OpenDOS where the serving PC is
unusable for anything else (and inflexible in the way you have to know
which client protocol will be used before they connect, making it
useless for modem answerring).
-------------------------------------------------------------------------
Mark Aitchison, \_ Phone: +64 3 364-2947 home 337-1225
Dept of Physics & Astronomy, </ Fax: +64 3 364-2469 or 364-2999
University of Canterbury, /) E-mail: phys169 AT csc DOT canterbury DOT ac DOT nz
Christchurch, NEW ZEALAND. (/' www.phys.canterbury.ac.nz/~physmsa
-------------------------------------------------------------------------
- Raw text -