Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!snorkelwacker!spdcc!ima!cfisun!lakart!dg
From: dg@lakart.UUCP (David Goodenough)
Newsgroups: comp.mail.uucp
Subject: Re: packet troubles
Message-ID: <743@lakart.UUCP>
Date: 8 Nov 89 23:46:50 GMT
References: <1989Nov7.090330.27599@polyslo.CalPoly.EDU>
Organization: Lakart Corporation, Newton, MA
Lines: 105

cambler@polyslo.CalPoly.EDU (Fubar) sez:
> The troubles with G protocol continue. Here is a debug script from my
> most bug-free version. It appears here unedited, comments in /* */ are
> added by me as i interpret things. If this sparks any insight for any
> g protocol hackers, PLEASE help!!!
> 
> BEGIN DEBUG SCRIPT: 

.....

> G3: open complete
> G3: buffers allocated
> G3: size arrays initialized
> 
> /* their init-c. they still say 7. THis isn't a problem, yes? I realize
>    that the open is complete, i malloc my buffers, etc... everything's
>    ok as far as i can see... */

Nothing wrong with a window size of 7 ..... see below

> 
> G3: 
>     MED SEND COMMAND: type = S  str =  D.polysloA0774 .......

.....

> G3:   Sending data packet 1
> G3: 
>     LOW PACKET OUT
> G3:     sending envelope
> G3:     sending data...
> G3: 
>     MED GET STRING:
> G3: 
>     LOW PACKET IN:
> G3:     reading...
> G3:     envelope in: tt = 0, xxx = 4, yyy = 0, need = 6
> G3: lenp = 0  oursum = 43658  theirsum = 43658
> G3:     sumok. packet received
> G3:     failure of getpkt, != TT_DATA
> G3: got TT_CTRL, xxx = 4
> 
> /* here's their response. I EXPECT a data packet with the "CY" in it,
>    but what i get is an xxx = 4, which is an RR 0. According to the
>    docs, g shouldn't acknowledge copy commands!!! It's not in ANY of
>    the other code i've looked at... the packets are all ok, as you
>    can see by the "sumok. packet received" message. */

Since when should it not ack the commands. If the "g" protocol driver is
written properly it shouldn't know the difference between a command and
a packet from a data file going. Consider the following scenario:

Message to send is:

D.polysloXA0774 D.polysloXA0774 christopher - D.polysloXA0774 0666

and a brain damaged receiver that only allows a window size of 1 (this is
legal, if inefficient). Now what happens? - the message to go is > 64
bytes, so it's going to take two packets.

Send packet 1

Can't send packet 2 till he ack's packet 1, but according to your
interpretation of the docs, he can't ack packet 1. You are going to have
a real long wait before pkt 2 goes.

Now let's see how BSD uucico does it:

rmesg - 'P' imsg looking for SYNC<\20>
imsg input<Ptfg\0>got 4 characters
got Ptfg
wmesg 'U' g		; all the external setup to get the "g" protocol
omsg <Ug>		; in use

send 073		; INITA window size 3
rec h->cntl 077		; his INITA window size 7

; window size 7 is perfectly legal, if a shade excessive. We use 3, and
; can keep data streaming at 9600 (provided the load average isn't too
; high :-) )

send 061		; INITB packet size 64 bytes
rec h->cntl 061		; his INITB packet size 64
send 053		; INITC window size 3
rec h->cntl 057		; his INITC window size 7
Proto started g
protocol g
(11/8-18:23-11604) OK (startup ttydx 1200 baud)
*** TOP ***  -  role=MASTER
(11/8-18:23-11604) REQUEST (S D.lakartB1pt2 D.lakartS1pt2 dg)
wmesg 'S'  D.lakartB1pt2 D.lakartS1pt2 dg - D.lakartB1pt2 0644
send 0210		; Outgoing data packet
rmesg - 'S'		; looking for an 'S' packet coming back
rec h->cntl 041		; Ah - what's this - an ack for the data
rec h->cntl 0211	; NOW comes his reply
send 041		; which we in turn ack
got SY			; and give the data to the upper level
PROCESS: msg - SY
SNDFILE:
send 0221		; file data .....
send 0231

and off it goes. I don't know which uucico you are using, but if you have
the source, when it's waiting for a data packet it should handle incoming
ack's and then settle down and wait again.
-- 
	dg@lakart.UUCP - David Goodenough		+---+
						IHS	| +-+-+
	....... !harvard!xait!lakart!dg			+-+-+ |
AKA:	dg%lakart.uucp@xait.xerox.com			  +---+