uucp level g protocol

[Dennis Bednar]

Recently there was some requests for info on the uucp level g protocol.
I dug up some old notes that I had, and recently editted them, based
on what I remember.  Here they are:


              The level g protocol (g-protocol) is a  link  level  protocol
         analogous  to X.25 level 2.  g-protocol uses timeouts, retransmis-
         sions,  acknowledgements,  and  packet  checksums   for   reliably
         transferring  information  from  one machine to another. Data sent
         from the user program on the sending machine is passed to the user
         program  on  the receiving machine, in the same order, and without
         loss or duplication.  Each machine has a send window which  limits
         the  number  of  outstanding  DATA  packets,  and serves as a flow
         control.  Ordering  is  maintained  by  adding  PS  (packet  send)
         sequence  numbers  on  the  sending  side, and by replying with PR
         (packet receive) sequence numbers on the acknowledging side.   The
         protocol  details  are  hidden from the user program on each side.
         The program on each side first issues an  open  call.  The  sender
         transmits  data  with  protocol write calls, and the receiver gets
         data with protocol read calls.  At the end of the link connection,
         both programs normally call a protocol close routine.

	[Ed note: level g is *functionally* the same as X.25 level 2,
	but the packet types, and packet formats are drastically different.
	For opening a connection, X.25 uses the SABM and UA frames,
	level g, however, uses the INITA, INITB, and INITC frames,
	both sides must send all 3 packets and receive all 3 packets.
	For transmission of DATA, X.25 uses I-frames, level g uses
	DATAL (data long), and DATAS (data short).  For acknowledgement
	purposes, both protocols use RR (Receiver Ready).
	X.25 has 2 frames that level g doesn't have: REJ, and RNR.
	For closing a connection, X.25 uses the DISC/UA sequence,
	uucp level g simply sends 2 consecutive CLOSE packets and
	doesn't wait for any confirmation.  In fact, it sends the
	2 CLOSE packets even when there are outstanding DATA packets,
	which is discussed again later.

	Also, the g protocol is typically imlemented in user programs,
	so that the protocol interfaces to the UNIX tty driver.
	However, the code has been written with #ifdef's so that
	it can be compiled, and run in the kernel, if desired.
	One of the earlier versions of UNIX had a pkon() call
	which, apparently, told the kernel tty driver to start doing
	the level g protocol.

	]


              g-protocol does not provide certain functions.  For instance,
         it does not provide routing any more elaborate than point-to-point
         between  two machines.  Also g-protocol does not support more than
         one connection over the link.

	[ Ed note: that is level g is a point-to-point protocol, parallel
	point-to-point links between the same machines are possible,
	but the data traffic on each link would be independent. ]

              There  are  certain  other  minor  deficiencies   that   were
         discovered while experimenting with the g-protocol:

	[ Ed note: these deficiencies were brought to my attention
	when I ran a personal program that runs on one machine, and
	illustrates the protocol in live operation. It is implemented
	by running the protocol in different 2 UNIX processes
	connected by UNIX pipes.  I hope to eventually post the source
	to net.sources. ]

              -  DATA  packets  are  always  always padded so that the DATA
         field is fixed length (64 bytes  in  this  version).   This  means
         wasted space in some packets, and decreased performance.

              -  it is possible to send less data than the send window size
         and close the connection without receiving any  error  indication:
         At  the local side, two protocol writes were issued, followed by a
         protocol close. The send window happened to be  3  packets.   Each
         protocol  write call returned "numwrote" (number of bytes written)
         that was the same as "num2write" (number of bytes to be written to
         network),  indicating  success.   Each  protocol write call caused
         data to be sent to  the  network,  but  it  was  not  acknowledged
         because  the  remote task was programmed to only call the protocol
         open code, but not to call its protocol read  routine.   Thus  the
         data  was  still  buffered  in  the  local  side's driver, and un-
         delivered when the call to the protocol close was issued.

	[ Ed note:  level g allows more than one DATA packet to be
	outstanding.  That is, several DATA packets can be sent,
	without having to wait for an explicit RR acknowledment packet
	for each one. Therefore, if you call pkwrite() the first time,
	pkwrite() sends the data over the link, and returns with
	success, even though the remote protocol was not prepared to read
	the data yet.  At this point the received data will be in
	the ttydriver's input buffer, but not yet passed on to the
	receiving program.  A copy of the data will also be in the
	sending protocol's send buffer, because the sender normally
	does not discard such data until it has been acknowledged.
	The fact that the pkclose() call does not
	attempt to make sure that outstanding DATA has been acknowledged,
	is, apparently, a bug in the protocol. ]
-- 
Dennis Bednar	Computer Consoles Inc.	Reston VA	703-648-3300
{decvax,ihnp4,harpo,allegra}!seismo!rlgvax!dennis