7 Oct
2024
7 Oct
'24
12:34 a.m.
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?
7 Oct
7 Oct
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
2:30 p.m.
On Oct 6, 2024, at 7:13 PM, Johnny Billquist
<bqt(a)softjar.se> wrote:
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.
...
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.
Yes, the typical use of connect data is for version number negotiation, which is a common
feature of DEC protocols. In that case, the connect confirm data contains the negotiated
version number -- the lower of what the two endpoints support. Occasionally something
else appears, for example in the MIRROR protocol where the connect init contains no data
and the connect confirm reports the max loop message size the mirror responder will
handle.
I'm not so sure of disconnect data; it might carry the version number of the sender if
a connect init is rejected due to version mismatch. The NICE spec would be expected to
say such a thing, but it doesn't.
paul
5:34 p.m.
On 2024-10-07 14:30, Paul Koning wrote:
MAIL11 actually stuffs file attributes in there, for the case that you
are sending a file. Pretty much all the RMS attributes. But of course,
that is very optional, and for mails with text, mailers don't care. And
the version number, and OS identifier is mostly for fun. But there are
also a word or two that tells what capabilities MAIL11 supports, and the
mail includes. Such things as if there is a CC: list of recipients as well.
So MAIL11 is pretty wild, if the optional data is used fully.
On Oct 6, 2024, at 7:13 PM, Johnny Billquist
<bqt(a)softjar.se> wrote:
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.
...
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.
Yes, the typical use of connect data is for version number negotiation, which is a common
feature of DEC protocols. In that case, the connect confirm data contains the negotiated
version number -- the lower of what the two endpoints support. Occasionally something
else appears, for example in the MIRROR protocol where the connect init contains no data
and the connect confirm reports the max loop message size the mirror responder will
handle. I'm not so sure of disconnect data; it might carry
the version number of the sender if a connect init is rejected due to version mismatch.
The NICE spec would be expected to say such a thing, but it doesn't.
Connect init reject is separate from disconnect.
And yes, the NICE spec is a bit lacking in some place, like this.
But I could for example think that you could include a reason for
disconnecting in the disconnect message.
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
75
days inactive
76
days old
3 comments
3 participants
participants (3)
-
Johnny Billquist -
Paul Koning -
Thomas DeBellis