[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