Path: utzoo!attcan!uunet!husc6!bloom-beacon!tut.cis.ohio-state.edu!mailrus!uflorida!haven!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.dcom.modems
Subject: Re: V.32 will dominate the marketplace (Was: Re: Which is best?)
Message-ID: <14576@mimsy.UUCP>
Date: 16 Nov 88 16:40:20 GMT
References: <2261@looking.UUCP> <1248@nusdhub.UUCP> <14515@mimsy.UUCP> <725@omen.UUCP>
Distribution: na
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 31

In article <725@omen.UUCP> caf@omen.UUCP (Chuck Forsberg WA7KGX) includes
everything (sigh) from article <14533@mimsy.UUCP>, in which I noted that

>>This [small delay, hoping to fill a packet] could be fixed by having
>>the tty driver speak a protocol with the modem, so that the modem
>>knows when to send immediately and when to wait.

>Unimportant in the case of ZMODEM and TrailBlazer modems.

Yes.  But not in the case of generic interactive traffic, or indeed
any other generic sort of traffic that does not involve long streams
of data (the ratio of traffic-where-it-matters to traffic-where-it-
does-not depends very much on your application; spoofed UUCP, or
unspoofed ZMODEM, transmission of netnews leans very far in the
does-not direction, for example).

>>(This is, of course, the moral equivalent of spoofing.)

>Adding a modest delay to data transmission is not the moral
>equivalent of spoofing.  Spoofing creates its own data and
>eats some data, all in the name of efficiency.

It is not the *delay* that is equivalent: it is the speaking of a
protocol directly with the modem.  If I reprogram my modem to speak
SLIP with my host, I have moved the `SLIP spoofing' up to the level of
a direct interaction with the modem.  The modem is no longer spoofing
per se, but the effect is the same:  the action has merely been
`legitimised'.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris