| <html> |
| <body> |
| <p> |
| Connections are the primary unit of resource management. |
| Sessions and Links are components of connections. When the |
| Connection is freed/discarded, any resources associated with |
| the Sessions and Links are automatically destroyed or discarded |
| as well. |
| </p> |
| |
| <p> |
| Each of the Connection, Session, and Link endpoints share a |
| common state model. Note that although this follows the same |
| pattern as the protocol state model for open/close, begin/end, |
| and attach/detach, this does not necessarily correspond one to |
| one to the protocol state model for endpoints. For example the |
| engine implementation may detach/reattach a link endpoint |
| without visibly changing the external state. |
| </p> |
| |
| <p> |
| The state of each endpoint is divided into two parts, one |
| reflecting the state of the local endpoint, and the other |
| reflecting the state of the remote endpoint as last |
| communicated. |
| </p> |
| |
| <pre> |
| LOCAL: |
| UNINIT |
| ACTIVE |
| CLOSED |
| |
| REMOTE: |
| UNINIT |
| ACTIVE |
| CLOSED |
| </pre> |
| |
| <p>In total there are 9 possible states:</p> |
| |
| <pre> |
| LOCAL REMOTE Example |
| ------------------------------------------------------------------------- |
| UNINIT UNINIT A newly created connection. |
| |
| UNINIT ACTIVE A remotely initiated connection |
| prior to full establishment. |
| |
| UNINIT CLOSED A remotely initiated connection that |
| has been closed prior to full |
| establishment. |
| |
| ACTIVE UNINIT A locally initiated connection prior |
| to full establishment. |
| |
| ACTIVE ACTIVE A fully established connection. |
| |
| ACTIVE CLOSED A remotely terminated connection. |
| |
| CLOSED UNINIT A locally initiated connection that |
| has been closed prior to full |
| establishment. |
| |
| CLOSED ACTIVE A locally terminated connection. |
| |
| CLOSED CLOSED A fully terminated connection. |
| </pre> |
| |
| <p> |
| Additionally each endpoint has an error slot which may be filled |
| with additional information regarding error conditions, e.g. why |
| the remote endpoint was transitioned to CLOSED. |
| </p> |
| |
| <h3>Questions:</h3> |
| |
| <ul> |
| <li>The transfer buffer class may not necessarily be explicitly part |
| of the external interface, e.g. it could be absorbed into the |
| session interface.</li> |
| <li>how do we confirm acheiving active/active without iterating |
| over all active/active endpoints? |
| <ul> |
| <li>add an ignore/interest flag as part of generic endpoint state?</li> |
| <li>add pending state to local state?</li> |
| </ul> |
| </li> |
| <li>what are credits exactly? |
| <ul> |
| <li>how does synchronous get work? |
| <ul><li>implies credit unit needs to be messages?</li></ul> |
| <li>credits may not correspond exactly with on-the-wire credits due |
| to local buffering</li> |
| </ul> |
| </li> |
| <li>how would 0-x impls work given that we're passing bytes directly to send? |
| <ul> |
| <li>have a generic property get/set API? |
| <ul><li>this could address per transfer flags as well</li></ul> |
| </li> |
| </ul> |
| </li> |
| <li>how do large messages work? |
| <ul><li>does send need a done flag for multiple transfers?</li></ul> |
| </li> |
| <li>how does resume work?</li> |
| <li>how does abort work?</li> |
| <li>how do we send settled? |
| <ul> |
| <li>just call settle on the returned transfer, the engine MUST optimize</li> |
| </ul> |
| </li> |
| <li> |
| how do we deal with send and receive modes on individual transfers? |
| <ul><li>could just twiddle the link ones and set them on the |
| transfer frame if they differ from what they were when the |
| attach was made</li></ul> |
| </li> |
| </ul> |
| </body> |
| </html> |
