26 Nov
2022
26 Nov
'22
5:49 p.m.
On 2022-11-26 17:10, Paul Koning wrote:
Well. I wouldn't call it a design error in TCP. It a different model,
and sometimes one model is better than the other for the specific
problem one wants to solve. That don't mean either model is any kind of
design error.
But the fact that in the IP world, there is no really reliable, packet
based protocol is a bit of a problem, because people often make
erroneous assumptions about TCP in this area. And the push function in
TCP have a good reason for existing. I would assume you knew that.
But yeah, TCP is very different than anything DECnet.
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. 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.
Right. And yeah, deferring sending of packets in DECnet would only make
sense if you actually are congested. But then any kind of push
functionality would again not make any difference or sense.
The Unix stream mode sockets over DECnet was an interesting detail. I
think I might have seen them mentioned before (maybe by John Forecast
then too?), but since noone else would understand them, it's hardly
relevant for TOPS-20. But it's cool to hear about, and I think it would
obviously not be hard to add such a layer in between, to get this kind
of semantics, if one wanted to.
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.
It probably is the way it is in RSX, since you want to have things
simple. I/O is usually always done directly from task memory. Extra
copying is only done by a few drivers, and is nice if the I/O might
block for long times, since if it's direct, then the task cannot be
swapped out until the I/O completes. But it requires more resources.
Extra memory allocated, extra copying done, and then mark that the task
is no longer blocked from swapping.
Much of the time send calls are not a problem, since they usually
complete pretty quickly. Worse with receive, since they might hang
around for a long time before completing. DECnet/RSX have an event
mailbox because of this, which you can get notified through when data
arrives, or whatever, without needing to have a pending I/O outstanding.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol