26 Nov
2022
26 Nov
'22
6:14 p.m.
On Nov 26, 2022, at 11:49 AM, Johnny Billquist
<bqt(a)softjar.se> wrote:
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.
When we originally designed that API using the event mailbox (Phase II timeframe) we had a
requirement from product management that DECnet-11M/S had to run on any valid -11M/S
system with at least 10KW of free memory and a supported comm device. A typical unmapped
system would run with only 3 buffers of 576 bytes each allocated to networking. Any
mechanism to reduce memory usage was considered. The worst was overlaying netacp; too many
paths through the system so simple changes caused the overlay structure to break. At the
end of the project the whole group spent a day buildings kits etc and, of course, the
overlay structure was broken and I had to spend the entire day putting a new one together.
BTW, we never met the 10KW goal but we did get it to fit in 11KW!
John.
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
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se