9 Apr
2020
9 Apr
'20
4:22 p.m.
On 6 Apr 2020, at 20:12, Paul Ruizendaal
<pnr(a)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.