From root Fri Nov 15 12:58:56 1985 Relay-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site man.UUCP Posting-Version: version B 2.10.2 9/18/84; site rlgvax.UUCP Path: man!gwsd!sdcsvax!sdcrdcf!hplabs!gatech!seismo!rlgvax!dennis From: dennis@rlgvax.UUCP (Dennis Bednar) Newsgroups: net.dcom,net.unix-wizards Subject: uucp level g protocol Message-ID: <841@rlgvax.UUCP> Date: 14 Nov 85 22:33:33 GMT Organization: CCI Office Systems Group, Reston, VA Lines: 101 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