17 Sep
2024
17 Sep
'24
10:48 p.m.
By the way - this is one of those things with DECnet that I do find a
bit "unfortunate". One write on the send side is matched by one read on
the receive side. Any data sent that is not read out by that one write
is lost, and you just get the data overrun error indicating that there
was data you missed.
Which is unlike TCP, where, since data is a stream of bytes, if you
don't read out some of the data in one read, it's there for the next one.
Of course, there are pros and cons with everything, but this one
requires that you have large buffers if you want to make sure to not
loose data, and since memory isn't exactly abundant on a 16-bit machine,
you need to do implementations that don't assume large buffers, unless
it's a very explicit design of the protocol.
Johnny
On 2024-09-17 22:25, Johnny Billquist wrote:
Urgh.... That will never be good.
Could you please send each line in a packet of its own?
Or at least keep the packets at a maximum of something like 256 bytes or
so?
Johnny
On 2024-09-17 22:13, Thomas DeBellis wrote:
--
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
Probably 2 or 3K if the finger plan is being
sent. That file would
all be sent in one buffer.
On 9/17/24 4:12 PM, Johnny Billquist wrote:
Thomas - checked a little on the RSX side.
I'm getting a data overrun error when receiving from VENTI2::
How much data are you sending in a single buffer???
Johnny
On 2024-09-17 21:48, Thomas DeBellis wrote:
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se Thanks, Terri, that is very kind of you to offer
this.
What a finger client will accept and produce has always been highly
installation dependent, the only consistency between all of them
being that the local folks thought theirs was the best, the highest
complement being when one finger adopted another finger's feature.
Tops-20 Finger will accept the following:
/CPU-IDLE /DETACHED /DIAL-IN /ETHERNET
/FULL-USER-NAME /HELP /INTERNET
/JOBNAME: /LOCAL /LOGIN /NETWORK
/NO-DETACHED /NO-OPERATOR /NO-PLAN
/OPERATOR /PTY /REAL-LOCATIONS /TERSE
/TTY-IDLE /TTY: /TYPE:
/VERBOSE /WHOIS
As can be seen, it is almost, but not quite entirely DECnet
innocent, which is not surprising as this is Standford's finger.
It's an accumulation of many years of separate authors and separate
styles and hacks that is kind of crying out for a substantial if not
complete rewrite. I don't believe I will have time for that for
another two years. For now, I'm just trying to get it to work on
DECnet without too many sparks flying out.
Columbia's finger did do a better job, but the underlying
implementation was another can of worms. Besides, those sourcesare
lost.
/COMMENT sounds interesting, but as I said, I'm still draining the
swamp, as it were and have not gotten past the alligators.
> ------------------------------------------------------------------------
>
> On 9/16/24 10:29 PM, Terri Kennedy wrote:
>
>> ------------------------------------------------------------------------
>>
>> On 2024-09-16 22:05, Thomas DeBellis wrote:
>>
>> As can be seen, the Tops-20 finger client has been modified to
>> send the name of the local user and optional data identifying the
>> finger client. Probably I'll change that to the finger
>> version. The RFC for TCP/IP finger is (naturally) silent on what
>> you can send over DECnet, so this doesn't break anything. So, I
>> can finger myself on MIM:: just fine, viz:
>
> DECnet uses the same sorts of qualifiers as the TCP/IP version.
>
> I had added a "/IAM=" qualifier to both VMS and RSTS/E Finger,
> but it is too easily abused in the modern age, particularly where
> not all nodes are under common management. The original intent was
> to have the server display "The user has the following unread mail
> messages from you" with a number, date/time, and subject.
>
> I will be removing it from both VMS and RSTS/E Finger (it will no
> longer send /IAM and will silently ignore any incoming /IAM).
>
>> If you have a finger client that can do DECnet connections on
>> another platform (I'm thinking VMS or maybe RSTS) and can try it,
>> let me know how you make out. Be aware that I did just hack this
>> together in two and a half days, so I make no claims to any sort
>> of stability. I'm just trying to trouble shoot at this point.
> As soon as I get on HECnet, I'll be glad to do any
> interoperability testing you want (and both the VAX and RSTS/E
> systems will have guest accounts, so you'll be able to log in and
> test for yourself).
>
> The currently implemented qualifiers in VMS Finger are:
>
> /ALL /BATCH /BYPASS /CPUTIME /FULL /HELP
> /IDLETIME /IMAGENAME /INTERACTIVE /LOCATION
> /LOGINTIME /MESSAGE /NETWORK /PERSONALNAME /PID
> /PROCESSNAME /SIZE /SORT /STATE /SUBPROCESS /SWAPPED
> /SYSTEM /TERMINAL /TTTYPE /USERNAME
>
> RSTS/E Finger ignores the ones that aren't relevant to that
> platform (or aren't implemented).
>
> I propose we add a "/COMMENT=quoted-string" qualifier.
> Implementations that don't support it will either complain or
> silently ignore it. Implementations that support it may choose to
> log that info (and anything else they care to) in an
> implementation-specific manner. I further suggest that the comment
> have a formal (if undocumented 8-) syntax, for example:
>
> /COMMENT="NODE:nodename,USER:username,VERS:finger-version"
>
> This will let humans (and possibly programs) parse that info with
> relative ease.
>
> What do people think about that?
> _______________________________________________
> HECnet mailing list -- hecnet(a)lists.dfupdate.se
> To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se