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)

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@lists.dfupdate.se
To unsubscribe send an email to hecnet-leave@lists.dfupdate.se