18 Jun
2024
18 Jun
'24
5:30 p.m.
On Jun 18, 2024, at 11:20 AM, Johnny Billquist
<bqt(a)softjar.se> wrote:
On 2024-06-18 16:00, Paul Koning wrote:
Hmm. Seems like this can degenerate into every call is a "send" type. Receive
will cause an ACK. Send, Connect, Conncect Confirm, Reject, Close, and so on all cause a
send. At least under RSX, I think the ACK only happens when the receiver have received the
message.
I meant a packet carrying application payload.
On Jun
17, 2024, at 9:54 PM, Johnny Billquist <bqt(a)softjar.se> wrote:
On 2024-06-17 22:44, Paul Koning wrote:
Yes,
because it sends a Connect Confirm message to the originator. > On Jun 16, 2024, at 7:03 PM, Johnny Billquist
<bqt(a)softjar.se> wrote:
>
> On 2024-06-16 22:40, Paul Koning wrote:
>>> On Jun 16, 2024, at 4:36 PM, Keith Halewood
<Keith.Halewood(a)pitbulluk.org> wrote:
>>>
>>> I approached this from VMS task communication. On a VMS host, I can write a
command procedure and create an object definition, say XXX, to output some data to SYS$NET
then refer to it remotely with something like
>>> TYPE node::"=XXX"
>>> This works quite well without the need for the caller to send something
first. I had hoped this would be the case with PyDECnet too.
>>> Is there any way of making a conn.accept() wait for the state change?
>> I could change the code to implement queueing until the state changes to RUN.
>
> Or you could not return from the accept until the state change to run?
Possible, but currently none of the "send" type API calls in PyDECnet do any
waiting. They either accept or reject the request, and if accepted they set it in motion,
but none wait for it to finish (for some definition of "finish").
Do you consider "accept" to be a "send" type call? But I do think the states would/should be triggered by
the appropriate call, or received packet.
I would not expect a connect to complete until the accept have happened on the other side
(or rejected). So I would think it's "waiting" no?
That's one design model, and it's a perfectly reasonable one, but it's not the
model I used.
So with accept, it wouldn't finish until the ACK
comes back. Sortof the same thing...
But in that case I wonder how you deal with connect. Because the connection is not
actually established until it has been accepted, and any sends before that point should
also not be possible.
Correct. And the answer is the same as with accept: if you issue connect and then
immediately a data send, you get WrongState. The connect API creates a connection object,
builds the Connect Initiate message, and sends it. That's all it does; retransmits
and the processing of accept or reject happen afterwards.
Anyway, I
do consider it to be a bit broken if, after the accept, you have some indeterminate time
when before you can call send. And I would hope you'd agree that this is a bit of a
headache for anyone using the API. Peronally, I would probably consider the accept to not
have completed until I can send data on the connection.
Fair enough. As I said, I
modeled the PyDECnet API on the architecture spec conceptual API (apart from polling). So
none of the sending calls wait for delivery. That's also the easiest to implement,
obviously. I will look at
a friendlier API that does implement waiting for the cases where there is a state change
and the next API call is going to need that state. Most likely I'll do that only in
the "Connectors" API, not in the module one. The reason is that the module API
lives right inside PyDECnet, so any kind of waiting is more problematic. Most
applications can be done just as well using the connectors API, with the application
running as a separate process. The management applications (NML and the event sender) do
need to be modules, obviously, but mirror and FAL and the like don't.
You know your implementation and its innards... I'm just reflecting on how I would
expect the API to work.