26 Nov
2022
26 Nov
'22
5:10 p.m.
On Nov 25, 2022, at 6:47 PM, Johnny Billquist
<bqt(a)softjar.se> wrote:
There is, as far as I know, no equivalent to push, since in DECnet, connections are never
handled as a stream of bytes, but as packets, and delivery is always immediate, and the
sending side is directly informed about the receiver actually receiving the packet.
It's essentially much more synchronous than TCP/IP. DECnet don't even necessarily
buffer on the sending side. At least with RSX, transmits goes directly from the task out
on the wire. And the send is only flagged complete when the receiving side have received
it. But on receiving side it might be in an internal buffer and not actually delivered to
the recipient task.
But I'm sure Paul remember more details.
However, one thing you do have in DECnet, which TCP/IP don't really do well, is that
you can send out of bounds, urgent data in DECnet.
Indeed, DECnet is a packet service rather than a stream service -- that was the one major
design error in TCP. And there is no such thing as a "push flag". I don't
know why there is in TCP, for that matter.
As for the transmit behavior, strictly speaking the DECnet architecture specs are only
protocol specs, not API specs. There are functions in the descriptive text that look
somewhat like an API, but they are intended merely as description and not as suggestions
-- let alone prescriptions -- for an API. For example, it's not likely any real API
uses a polled model, as the description does. Not even PyDECnet, which in many respects
does look a fair amount like the model descriptions.
So while it's reasonable to expect that the actual OS API for DECnet transmit
corresponds directly to a packet going out right then, I'm not sure you could actually
point to DECnet spec text that requires such behavior. I do expect that everyone does
that, with the possible exception of DEC Unix when using "stream mode" sockets.
There would be any good reason to delay sending an offered packet, since there isn't
much of anything that could be done differently if one were to do so. TCP is entirely
different, there deferring transmit allows the possible addition of more bytes to the
packet. That's not a possibility in DECnet.
On the subject of completion, that's an API choice. RSTS does it differently from
RSX, its API for transmit means "queue a request for transmission", and the call
completes as soon as the message has been accepted into the outbound queue. Transmission
on the wire happens right away if flow control permits, or later if there is no current
permission to send. The ACK from the other end willl stop retransmits and remove the
packet from the transmit queue.
paul