17 Jun
2024
17 Jun
'24
1:03 a.m.
On 2024-06-16 22:40, Paul Koning wrote:
Or you could not return from the accept until the state change to run?
Depending on how far away the machines are, the speed of the machines,
and whatnot, multiple seconds are not necessarily anything strange at all.
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
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. I tried
implementing a retry mechanism when WrongState occurs but even after a few seconds, the
response remains WrongState.
I am tempted to return to my previous solution of a two way task. In the case of
timestamp, the client sends the timezone of interest and the object responds with the
appropriate timestamp.
If the destination state remains CC for multiple seconds, that suggests there's a bug
in the originating end. It might help if you could do a packet capture (tcpdump to a
capture file) for both the case that doesn't work and the case that does (the two way
task).