7 Oct
2024
7 Oct
'24
1:13 a.m.
The 16 bytes of optional data at connect and disconnect time can be
generated by both sides, and read by the other side optionally.
I don't know how TOPS-20 do things around this, but here is what I know
from RSX:
When a connect request is sent, the request can include up to 16 bytes
of data. The process that receives the connect request can read this
data out, even before accepting the connection.
If the connection is rejected, an optional up to 16 bytes of data can be
sent in the reject.
If the connection is accepted, an optional up to 16 bytes of data can be
sent in the accept.
In both cases, the process that initiated the connect can read out these
bytes, along with the information if the connection was accepted or
rejected.
When it comes to disconnecting, again, the side that initiates the
disconnect can at that time send up to 16 bytes of optional data, that
the received can read out.
Not that all of this is optional data. There is no hard requirement that
the either side actually sends something, or that the receiving side
actually reads out any of it. It have no direct impact on the connection
as such. It truly is just optional data.
DEC have made use of this in some cases:
MAIL11 can send information about the actual mailer, with versions and
stuff in the optional data (however, VMS do handle this in a slightly
careless way).
NICE use it to inform which version of the NICE protocol is used, so
that other other side can understand and also adjust. It's a sort of
negotiation going on for this one, and TOPS-20 *must* be implementing it
there, so there is one place you should be able to find something.
There might be others, but I haven't actually searched. I just happen to
know about these two since I've written software that speaks those
protocols.
Johnny
On 2024-10-07 00:34, Thomas DeBellis wrote:
I've finished the timeout functionality so that
the Tops-20 finger
server will only wait so long before punting the connection (don't
worry, I'm very generous...)
I'm now working on the logging functionality. Again, on a connection
interrupt, the finger server grabs a bunch of meta-data about the
connection and displays it:
FNGSRV(1): Sunday, 6-October-2024 12:23:36.52412 AM-EDT
From: VENTI2, User: SLOGIN, Data: STREAM*
Object Type: Generic (FINGER), Segment Size: 1459
Local Flow Control: Segment, Remote Flow Control: Segment
Link Quota: Input Percentage: 50, Buffers: 16, Input Goal: 0
I have three concerns here (or maybe two and a half)
1)I want to write this information to a log file,
2)Since the data is written by concurrent server sub-forks,
a)Data can get overwritten
b)Latency to start the finger sub-sub-forks is increased
The solution is simple enough, I grab everything in the server sub-fork
and ship it up to the controller through shared memory for later
formatting and storage (and maybe printing).
When reviewing what meta-data can be gotten, I noticed that an explicit
connection confirm (MTOPR% function .MOCC) can take a pointer to an
optional sixteen bytes of data. What I can't quite tell from the
documentation is whether the server reads this or whether the server
writes it. I find myself being unsure of the wording.
1. If the former (server sends), how does the client read it?
2. If the latter (server reads), how does the client send it?
I don't see a single instance of any Tops-20 DECnet program using this,
so no help there. I /think/ this is case 1., that is, the server has
the option of writing it. However, I was wondering what specification
this is in (maybe NSP 4?) and where, so I could read it before I look at
the monitor sources to see how the client would read it. I'm assuming
it would show up at the client as optional data?
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
--
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