7 Oct
2020
7 Oct
'20
3:42 p.m.
Ethan Dicks wrote:
There are no implementations of sync serial devices in Simh. That
would have to be written in any case. The DU11 and DUV11 are very
simple PIO serial lines with, IIRC, a COM5025 USART. It would not be
a huge undertaking to write up a module to emulate one and attach it
to the virtual bus and have it also just open up a TCP socket.
One could use 'netcat' or something similar to open up and talk to
both the PDP-11 socket and the Hercules socket to make the connection.
This is (more or less, not exactly) what the orginal 2703/bisync emulation
in Hercules does but it is not really sufficient for RJE, for a number of
reasons.
The bisync/RJE protocol is a great fit for being generated by hardware and
being sent over a dedicated line. It is a poor fit for being generated
by software and being sent over a shared TCP/IP network. There is lots
of bandwidth wasting chatter and lots of CPU is consumed in mostly achieving
nothing useful.
The bisync/RJE protocol needs a close to real-time response and is not a
good fit for a network which can produce variable delays. Buffers in
applications tend to be organised on a just-in-time basis. The flow control
needs to be able to tell the far end to stop sending data immediately and
dribble in shortly as network buffers get cleared or unexpectedly delayed
packets arrive. One end also expects that once data is successfully sent
out, it is practically sure to arrive almost immediately at the far end,
not get piled into buffers and suffer random delays. (I have tried assuming
that if sufficient TCP/IP network bandwidth is provided, the flow control
will not get triggered. This didn't work. In practice, if one end has data
to send, it will keep blasting it out until the far end tells it to stop and
then it expects it to stop near instantly.) Applications tend to be coded
with fixed, short timeout values.
Interesting stuff happens if the TCP/IP socket is not connected when attempts
are made to send data. Applications tend to assume that any errors are fatal
and they just give up.
The link I included describes how to avoid these difficulties for NJE
by using a very different protocol which is specifically designed for sending
NJE over TCP/IP networks. I believe a similar approach is needed to do RJE
successfully, especially if it is to end up working across the internet rather
than just across a lab under ideal conditions.
Regards,
Peter Coghlan.