16 Jun
2024
16 Jun
'24
9:33 p.m.
I'm trying to understand this, but am sortof failing, Paul.
As a sortof sidetrack, when I saw the start of this topic, I went and
worked over an API I have for this from PDP-11 C in RSX, so I can easily
write and test communicating with DECnet tasks under RSX.
Under RSX, the connecting side does a CONNECT call, which includes both
the sending of data for the connect, as well as receiving the data from
the accept. So clearly, when this call finishes, the connection have
been fully established, since the accept data is returned by the call.
The server side, on the other hand is receiving a connection request,
and if it does an ACCEPT of it, which includes sending some data carried
with the accept, you then are clear to send or receive data right away.
There is no additional ACK information passed in any way after that. And
I can't see how it would be needed, either. You know the other side sent
the connect, so as soon as you have accepted, the connection is up and
available.
It would be close to unusable if the receiving side could not send data
for an indeterminate period after accepting a connection, unless the
other side sends something first.
Happy to help if there is something you'd want to test against RSX.
Johnny
On 2024-06-16 20:08, Paul Koning 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
On Jun 15, 2024, at 5:50 PM, Keith Halewood
<Keith.Halewood(a)pitbulluk.org <mailto:Keith.Halewood@pitbulluk.org>>
wrote:
Hi,
I think there’s a bug in in decnet/nsp.py, line 1173
A phase 3 accept is setting its state toself.cc <http://self.cc/>which
doesn’t seem to exist. If I change that to self.run, like the state
setting for phase 2 accept, I can then send a message after accepting
the connection without ‘WrongState’ being thrown.
This is pydecnet 1.1-648.
Keith
More on this: there's an assymetry in the 3-way handshake: the
initiating side can start sending data as soon as it receives the accept
(that data doubles as the confirm ack). But the responding side has to
wait for the connect confirm to be acknowledged before sending any data.
This asymmetry makes some sense because most applications have the
initiating side sending the first data message. But if you have an
application where the responding side sends the first data message you
have to wait for the ack. The simplest way is to catch the WrongState
error and retry after a brief pause.
paul
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se