[HECnet] Re: PyDECnet additional network objects

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 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. Regards Keith -----Original Message----- From: Paul Koning [mailto:paulkoning@comcast.net] Sent: 16 June 2024 21:03 To: Johnny Billquist <bqt(a)softjar.se> Cc: hecnet(a)lists.dfupdate.se Subject: [HECnet] Re: PyDECnet additional network objects There's a difference between the API any given DECnet implementation offers, and the network protocol. Also, the DECnet architecture spec describes its operation through a model API, though that API is merely for information and not required. PyDECnet approximately implements the model API, with the exception of its polling approach. In the NSP architecture there is a description of the connection states, and what can be sent or done in each state. For example, when you send a connect initiate (as the CONNECT call you mentioned does) the initial state is CI, and when the other side ACKs the CI message the state becomes CD ("connect delivered"). At this point, data cannot be sent yet. When the receiving end does an ACCEPT, a Connect Confirm message is sent and the state at that end becomes CC. Once the Confirm message is delivered to the originator, that side goes into RUN state, it sends an ACK (possibly piggybacked) and can now send data. The receiving end, when it sees the ACK or data, also goes to RUN state, and can then send data. All that is in the NSP spec. Note in particular that the receiving end can't send data while in CC state. Given that RSX allows sending data immediately after the ACCEPT call, the implication is that it's buffering those data requests until the transition to RUN, at which point it's allowed to send them. That's a fine implementation and perhaps I should change PyDECnet to do the same, but currently it doesn't do that; instead it follows the NSP model (Phase IV NSP spec, page 37). BTW, the CC doesn't last an indeterminate period. The NSP spec says the originator must ACK the connect confirm message. It can do that with a data message or a separate ACK, but either way the CC state will transition to RUN as soon as that answer is delivered to the far end. So the CC state is very short lived, just long enough for an ACK round trip (unless a retransmit is needed). The reason Phase II doesn't have a CC state is that it assumes a reliable network, which Phase III and beyond assume a datagram network layer. So Phase II has no need for retransmits (at the NSP level), nor timeouts, nor any states that deal with the possibiility of packet loss. paul _______________________________________________ HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se