Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 alpha 5/22/85; site cbosgd.UUCP
Path: utzoo!watmath!clyde!cbosgd!mark
From: mark@cbosgd.UUCP (Mark Horton)
Newsgroups: net.dcom
Subject: Re: MNP Proposed as Industry Standard
Message-ID: <1716@cbosgd.UUCP>
Date: Fri, 27-Dec-85 18:41:25 EST
Article-I.D.: cbosgd.1716
Posted: Fri Dec 27 18:41:25 1985
Date-Received: Sat, 28-Dec-85 04:40:06 EST
References: <213@gould9.UUCP> <557@adelie.UUCP> <1956@hplabs.UUCP> <283@ius2.cs.cmu.edu> <1961@hplabs.UUCP> <559@adelie.UUCP>
Organization: AT&T Bell Laboratories, Columbus, Oh
Lines: 19

For true HOST-HOST communication, ala TCP/IP or UUCP or X.25 or OSI or
whatever, there are end-to-end protocols that make things like MNP
unnecessary (and the overhead could hurt throughput.)

But for ordinary RS232 "lowest common denominator" terminals, especially
over possibly noisy dialup lines, MNP could be a big win.  But it's not
perfect - lack of flow control can still cause you to drop data if the
producer creates bursts that the consumer can't handle in real time.

I'm not very familiar with MNP, but I seem to recall hearing that it
uses the start and stop bits (recall that async links send 10 bits for
each 8 bit character, using start and stop for framing) for the extra
information.  This means there is no slowdown.  It also means that you
cannot send a BREAK over such a line, and I seem to recall hearing someone
saying that you can't send a BREAK with MNP.  This only matters for users
of terminals, since host protocols don't generally use BREAK, but then the
terminal users are the ones who benefit most from MNP.

	Mark