Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 Adelie 8/14/85; site adelie.UUCP Path: utzoo!watmath!clyde!burl!ulysses!gamma!epsilon!zeta!sabre!petrus!bellcore!decvax!decwrl!pyramid!ut-sally!seismo!harvard!adelie!barry From: barry@adelie.UUCP (Barry A. Burke) Newsgroups: net.dcom Subject: Re: MNP Proposed as Industry Standard Message-ID: <559@adelie.UUCP> Date: Tue, 24-Dec-85 10:42:37 EST Article-I.D.: adelie.559 Posted: Tue Dec 24 10:42:37 1985 Date-Received: Wed, 25-Dec-85 23:34:07 EST References: <213@gould9.UUCP> <557@adelie.UUCP> <1956@hplabs.UUCP> <283@ius2.cs.cmu.edu> <1961@hplabs.UUCP> Reply-To: barry@adelie.UUCP (Barry A. Burke) Organization: Adelie Corporation, Newtonville MA Lines: 78 Keywords: Can you say "Layered Protocols"? Summary: Expansion on previous followup (long-ish, sorry!) >> >> It's not clear whether >> >> anything can be gained (or if it's even possible) by running MNP in >> >> software in say, your PC's terminal emulator. > > My question was (intended to be), can I run MNP in software >if I have a terminal emulator running on a general-purpose computer system? >or is MNP hard-tied into the data-transmission circuits/algorithms in >the modem? > >Ralph's reply, which makes sense to me, seems to say that running >any error-correction protocol "closer" to the application is >a good thing. This would mean that running MNP in my terminal emulator >would be a good thing. > I obviously was not very explicit in my original posting regarding the above statement. What I am saying is that MNP is quite likely a time-based correction protocol, as it was developed to run on modem hardware (as opposed to X.PC, which was designed to run in the PC itself). To maintain the high throughput of MNP (it's effectively transparent on clean lines- low overhead), I suspect that a time-synchronous factor is included in the missed packet/packet framing componenet of MNP. This would enable packets to be simply framed and checksummed. X.PC, on the otherhand, must have a much more X.25-like framing in order to handle multiple sessions over the link. What I'm driving at is that MNP is a reasonably effective and efficient error correction protocol for the physical layer, but it probably can't well be implemented in software on a GP PC or timesharing system, because of it's origin as a component of a piece of comms hardware. Running MNP in userspace on your VAX might be much like running SDLC without any hardware to help- good luck. And while I agree that error correction (and recovery) really must be done at the application level, error recovery at lower levels can reduce the overal data-flow overhead, as the higher up the problems must be RECOVERED from, the more the overhead to perform the recovery (note that the DETECTION overhead is predictably constant at each level). So, for me, I'd prefer the following (as an example): PC Remote HOST ============ =========== APPLICATION <--- (Appl. ERROR CORRECTION) ---> APPLICATION CLIENT SERVER v v v v X.PC <--- (X.PC ERROR CORRECTION) ---> X.PC CLIENT [running on Host CPU] SERVER v v v v MNP <--- (MNP ERROR CORRECTION) ---> MNP MODEM [running in Modems] MODEM v v v v - - - - - - - - - - - - - - -/ /- - - - - - - - - - - - - Too much of today's Application software assumes clean, clear data transfer to/from the remote device- a case that's not even 99% true for direct connect devices, much less anyhting that connectes over phone lines. MNP (in my opinion) tries to make the phone lines look clear, but do NOT protect from every data error the Application may see. Likewise, X.PC (I've worked for years over X.25 links- the only thing that's assured is that whatever garbage you put in one side will come out the other, in the right order!). If you want error-free, you have to do error correction at the application. BUT since pending flushes, data re-packetizing, and retransmission is expressed in CPU & memory use overhead- you'll get a better PERFORMING package if you use a recovery protocol at several different layers. Remember, the best performing error recovery implementation is one that costs nothing to detect errors, and never has to correct any! -- LIVE: Barry A. Burke, (617) 965-8480 x26 USPS: Adelie Corporation, 288 Walnut St., Newtonville, MA 02160 UUCP: ..!{harvard | decvax!linus!axiom}!adelie!barry ARPA: adelie!barry@harvard.HARVARD.EDU, barry%adelie.UUCP@harvard.HARVARD.EDU