16 Jun
2024
16 Jun
'24
10:58 p.m.
Hi Paul,
I'll have a go at tracing both cases.
Keith
-----Original Message-----
From: Paul Koning [mailto:paulkoning@comcast.net]
Sent: 16 June 2024 21:40
To: The Hobbyist DECnet mailing list <hecnet(a)lists.dfupdate.se>
Subject: [HECnet] Re: PyDECnet additional network objects
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).
paul
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to
hecnet-leave(a)lists.dfupdate.se