Editing UUCP (section)

===g-protocol===
Within the suite of protocols in UUCP, the underlying g-protocol is responsible for transferring information in an error-free form. The protocol originated as a general-purpose system for packet delivery, and thus offers a number of features that are not used by the UUCP package as a whole. These include a secondary channel that can send command data interspersed with a file transfer, and the ability to renegotiate the packet and window sizes during transmission. These extra features may not be available in some implementations of the UUCP stack.<ref name=faq>{{cite web |url=http://www.math.utah.edu/docs/info/uucp_5.html |title=UUCP Internals Frequently Asked Questions |first=Ian Lance |last=Taylor |date=8 March 1996 |access-date=29 August 2020 |archive-date=6 November 2019 |archive-url=https://web.archive.org/web/20191106212355/http://www.math.utah.edu/docs/info/uucp_5.html |url-status=live }}</ref>

The packet format consisted of a 6-byte header and then between zero and 4096 bytes in the payload. The packet starts with a single \020 (control-P). This is followed by a single byte, known as "K", containing a value of 1 to 8 indicating a packet size from 32 to 4096 bytes, or a 9 indicating a control packet. Many systems only supported K=2, meaning 64 bytes. The next two bytes were a 16-bit checksum of the payload, not including the header. The next byte is the data type and finally, the last byte is the XOR of the header, allowing it to be checked separately from the payload.<ref name=faq/>

The control byte consists of three bit-fields in the format TTXXXYYY. TT is the packet type, 0 for control packets (which also requires K=9 to be valid), 1 for alternate data (not used in UUCP), 2 for data, and 3 indicates a short packet that re-defines the meaning of K. In a data packet, XXX is the packet number for this packet from 0 to 7, and YYY is the last that was received correctly. This provides up to 8 packets in a window. In a control packet, XXX indicates the command and YYY is used for various parameters. For instance, transfers are started by sending a short control packet with TT=0 (control), XXX=7 and YYY the number of packets in a window, then sending another packet with XXX=6 and YYY as the packet length (encoded as it would be in K) and then a third packet that is identical to the first but XXX=5.<ref name=faq/>

g-protocol uses a simple [[sliding window]] system to deal with potentially long latencies between endpoints. The protocol allows packets to size from 32 to 4096 8-bit bytes, and windows that include 1 to 7 packets. In theory, a system using 4k packets and 7 packet windows (4096x7) would offer performance matching or beating the best file-transfer protocols like [[ZMODEM]]. In practice, many early implementations only supported a single setting of 64x3. As a result, the g-protocol has an undeserved reputation for poor performance. Confusion over the packet and window sizes led to the G-protocol, differing only in that it always used 4096x3. Taylor UUCP did not support G, but did support any valid requested window or packet size, so remote systems starting G would work fine with Taylor's g, while two Taylor systems could negotiate even faster connections.<ref name=faq/>

[[Telebit]] modems used [[protocol spoofing]] to improve the performance of g-protocol transfers by noticing end-of-packet markers being sent to the remote system and immediately sending an {{code|ACK}} back to the local host, pretending that the remote system had already received the packet and decoded it correctly. This triggered the software stack on the local computer to send the next packet, so rapidly that the transfer became almost continuous. The data between the two modems was error-corrected using a proprietary protocol based on [[Microcom Networking Protocol|MNP]] that ran over Telebit's half-duplex connections much better than g-protocol would normally,<ref name=faq/> because in the common 64x3 case the remote system would be sending a constant stream of {{code|ACK}}s that would overflow the low-speed return channel. Combined with the modem's naturally higher data rates, up to 23&nbsp;kbps, they greatly improved overall throughput and generally performed about seven times the speed of a 2400 bit/s modem.<ref>{{cite web |url=http://www.umich.edu/~archive/mac/misc/documentation/telecomminfo.txt |title=What You Need To Know About Modems |first=Kenneth |last=Kirksey |date=25 December 1991 |quote=The actual throughput is around 14400 bps. |access-date=29 August 2020 |archive-date=24 October 2020 |archive-url=https://web.archive.org/web/20201024183419/http://www.umich.edu/~archive/mac/misc/documentation/telecomminfo.txt |url-status=live }}</ref> They were widely used on UUCP hosts as they could quickly pay for themselves in reduced long-distance charges.