Re: [TUHS] PK protocol

[Paul Ruizendaal <pnr@planet.nl>]

> On 6 Apr 2020, at 20:12, Paul Ruizendaal <pnr@planet.nl> wrote:
> 
> Now I’m wondering. It looks like UUCP packet "protocol g” is maybe much the same as the original (“Chesson”) packet algorithm for Datakit, and if so it would be “dual use”. It would seem that in V7 line discipline ‘0’ was normal tty handling, discipline ‘1’ was PK protocol over serial and line discipline ‘2’ was PK protocol over something with CRC in the driver - whatever that was.
> 
> Am I on the right track?

It seems the story is more complicated. In a 1993 retrospective Fraser writes:

"The first Datakit protocols used a packet structure that was aligned with cell boundaries. Chesson designed a file transfer protocol that transported data in variable length packets, each ending with a trailer. There was no packet header. It was argued that it is easy to generate a trailer after the body of a packet has been transmitted, and that control information in a trailer arrives at the receiver just when the receiver is ready to process that information.”

Fraser uses the plural “the first protocols”: it would seem that there is not a single reference point. It also mentions that the protocols used a trailer, which does not match with the PK protocol. On the other hand this is a reference to a “file transfer protocol” which is not the same as a “link protocol”.

Also, Chesson wrote a note on the PK driver a few years after the V7 release (e.g. here: https://pd.spuddy.org/fs/simtel20/uucp/uucproto.des). In this note he writes:

"The resemblance between the flow control procedure in the packet driver and that defined for X.25 is no accident. The packet driver protocol began life as an attempt at cleaning up X.25.  That is why, for example, control information is uniform in length (one byte), there is no RNR message (not needed), and there is but one timeout defined in the sender.”

Earlier in the note Chesson also emphasised that the PK protocol was used for variation and experimentation. In the X.25 context, the reference to a CRC-based driver in the PK source may refer to a HDLC-like physical link.

All in all it would seem that the PK driver is *not* what was used as an early Datakit protocol. However, it is probably the best proxy for what such a driver looked like that we  have. It would seem likely to me that for instance the buffer strategy used in the PK driver would be about the same as that used for the Datakit driver(s) in V7.

It is possible that a variation of the PK protocol was used for Datakit around V7 time.