telecom@ucbvax.UUCP (12/24/85)
>> >> 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
telecom@ucbvax.UUCP (01/02/86)
There seems to be some confusion as to whether it is possible to implement MNP on a regular computer, rather than in the modem. The answer seems to be yes, since I am at this moment typing on an IBM PC running a modem program from Microcom which implements MNP with (I think) no help from the modem. MNP is actually a family of protocols, including reliable link mode, which is like Telnet, and reliable file transfer which is like FTP. The reliable link mode does seem not to allow breaks, and is a little spazzy in very interactive use. I usually use it when dialing into Telenet, logging in to some computer and having it blat a lot of data at me, which works well. The file transfer mode works great and seems to be faster than any other commonly available PC protocol. (RBBS-PC, a common bulletin board program, supports it.) It's a big win over XMODEM. There are also features that I don't really understand which are supposed to help when transferring files between computers that have different opinions about e.g. end of line characters. John Levine, ima!johnl
telecom@ucbvax.UUCP (01/03/86)
> 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 the key word "can", not "will". Upper levels sometimes need do *less* work to perform recovery, because they know more about what's going on. An extreme case is packet voice, where it is usually better *not* to attempt recovery at all, because the delay involved in recovery is much more audible than just forgetting the bad packet altogether and faking it until the next good one arrives. (How to "fake it"? Repeat the last packet. Or hold the sound output constant at the last value of the last packet. Or do any of several more complicated things. All less audible than a gap.) Also don't forget that layered protocols can exact a terrible price in performance, because of multiple layers of overhead. If your lines are noisy and your performance needs are both moderate and orthodox, low-level recovery is probably a win even though one does need end-to-end checks as well. If you care a lot about performance and your transmission medium is pretty good (e.g. Ethernet), the situation looks very different. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry