Date: Wed, 17 Dec 1997 11:38:20 +1300 From: physmsa AT cantua DOT canterbury DOT ac DOT nz (Mr M S Aitchison) Subject: FileLink/Interserver (was Re: OD7.02B - Should I upgrade to it?) To: opendos AT delorie DOT com Message-id: <199712162238.LAA13659@cantua.canterbury.ac.nz> Precedence: bulk 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,