Path: utzoo!yunexus!geac!syntron!jtsv16!uunet!munnari!vuwcomp!duncan
From: duncan@comp.vuw.ac.nz (Duncan McEwan)
Newsgroups: comp.dcom.modems
Subject: Re: TrailBlazer and UUCP
Message-ID: <14179@comp.vuw.ac.nz>
Date: 5 Sep 88 00:33:36 GMT
Article-I.D.: comp.14179
References: <467@njsmu.UUCP> <6453@chinet.UUCP> <4560@umix.cc.umich.edu>
Reply-To: duncan@comp.vuw.ac.nz (Duncan McEwan)
Organization: Comp Sci, Victoria Univ, Wellington, New Zealand
Lines: 22

In <4560@umix.cc.umich.edu> honey@citi.umich.edu (Peter Honeyman) writes:
>stripping the 'g' frame would require spoofing the upper level as well.

Why does simply stripping the 'g' frame from each packet mean that the
tb has to know about the H, S, C, etc messages?  What am I missing?

>this is hard, so the tb doesn't bother; it sends the 'g' frame intact
>and models the 'g' state machine.

If full 'g' frames are sent intact, what exactly does the tb's 'g' protocol
spoofing involve and what do you gain from it?  I can see that if the tb
generates ack's locally, the local uucico would not have to wait for a full
round trip time to receive it, but that is what the send window is for isn't
it?

Answers by email would probably be best since I guess most readers of
this group are familiar with the Trailblazer.  They have only just
become available in NZ, and all I know about them is what I have read
in comp.dcom.modems and the advertising glossies.  I haven't seen much
about the 'g' protocol spoofing in either.

Duncan