26 Nov
2022
26 Nov
'22
2:02 a.m.
Yes, agreed.
However, I'm not sure if you and I are talking about the same level in
the network stack. I had meant to only talk about the network stack in
an implied and tangential manner.
What I was getting is that SOUTR% is used in TCP to push accumulated
data out. There is no idea of a record, it's just doing a push. From
the code that I am seeing in FAL and NFT, it appears that SOUTR% is
being used in the same way. I should have clarified that both SOUT% and
SOUTR% view the data as a stream of bytes (of varying widths, of
course). There is only a record on those media that support it,
magnetic tape as far as I remember.
I /think/ I may have fixed my most recent bug. I had put a data
transfer optimization in from some code that I wrote in Kermit-20 for
the NRT and PTY driver that I had picked up from my FTP server. It
tickles a completely understandable run condition which can not occur in
Kermit but can in DAP because Kermit is acknowledging individual packets
at the application level while DAP does not.
Well, that's what I think so far while I'm testing. One hopeful result
is that an anonymous directory listing against MIM:: works now. Well,
works /mostly/. I'm getting the error below:
NNQUERY.C;208 Remote status - File protection violation (MAC:4
MIC:125 STV:0)
.
.
.
NNQUERY.C;199 Remote status - File protection violation (MAC:4
MIC:125 STV:0)
NNQUERY.MAP;285;P775656 17 34816(8) 18-Oct-2022 09:59:35
I think this is correct, because when I logged into MIM:: and checked
further, I got:
$ *dsp DU1:[DECNET]NNQUERY.C;208*
?DSP-F-OPNINP, Error opening DU1:[DECNET]NNQUERY.C;208 as input
-RMS-E-ER$PRV, Privilege violation
I don't remember protected files like that in DU1:[DECNET], but it's
been awhile since I've tested against multiple systems (last May, in fact)
On 11/25/22 6:47 PM, Johnny Billquist 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.
Johnny
On 2022-11-26 00:05, Thomas DeBellis wrote:
In TCP, something called the 'push flag'
can be set to cause
accumulated data in the monitor (which may be one or more packets) to
be sent over the network. It is often abbreviated as "PSH".
The Tops-20 FTP client and server both set PSH on the last packet of
data from a file to send it on its way. This is done with a SOUTR%
JSYS, which stands for *S*tring *OUT* *R*ecord. This is an
overloading of the hardware record concept which is more commonly
associated with nine-track magnetic tape.
PSH can also be detected on input by doing a SINR%, which stops the
network read early, instead of waiting for a full buffer of data
(which might, in fact, never come).
I believe DECnet transport implements the same semantics, but I would
like to double check that. Where would I go in which part of what
specification? Or does anybody know?
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se