18 Jun
2024
18 Jun
'24
4 p.m.
On Jun 17, 2024, at 9:54 PM, Johnny Billquist
<bqt(a)softjar.se> wrote:
On 2024-06-17 22:44, Paul Koning wrote:
Do you consider "accept" to be a "send" type call?
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:
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"). > 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? 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.
paul