Formalize the Ping Protocol #575
Conversation
Signed-off-by: sappenin <[email protected]>
Signed-off-by: sappenin <[email protected]>
Signed-off-by: sappenin <[email protected]>
Signed-off-by: sappenin <[email protected]>
…ional-flow. Signed-off-by: Taiga Nakayama <[email protected]>
Add images for the unidirectional-flow and bidirectional-flow.
Co-Authored-By: Evan Schwartz <[email protected]>
Co-Authored-By: Evan Schwartz <[email protected]>
Co-Authored-By: Evan Schwartz <[email protected]>
Co-Authored-By: Evan Schwartz <[email protected]>
* Reword various paragraphs with new suggested terminology. * Move mode-specific portions to the appropriate sections. * Improve Implementation Considerations. * Add link to OER encoding notes. * Fix ordered-list numbering Signed-off-by: sappenin <[email protected]>
Signed-off-by: sappenin <[email protected]>
Signed-off-by: sappenin <[email protected]>
Signed-off-by: sappenin <[email protected]>
* Update ping protocol verbiage * Update svg flow for bidirectional mode. Signed-off-by: sappenin <[email protected]>
Signed-off-by: sappenin <[email protected]>
There was a problem hiding this comment.
Thanks for this @sappenin . Mostly looks good to me. The only question/comment I have is should the unidirectional flow also have a predefined data payload. The reason I ask is because I am unsure what mechanism the receiver would know that this is specifically a PING packet. Rather than a random packet addressed to it.
In unidirectional mode, the receiver knows this is a In my mind, there's no data payload needed in unidirectional flow. In bi-directional flow, the data payload is needed to signal receiver where to send the |
| <g id="Graphic_8"> | ||
| <title>Text</title> | ||
| <text transform="translate(112.65458 326.66667)" fill="black"> | ||
| <tspan font-family="Courier" font-size="12" font-weight="400" fill="black" x="0" y="11">(4)Fulfill</tspan> |
There was a problem hiding this comment.
I think this should be 6
The recipient sends the packet to the sender (4) and then the sender would fulfill it (5) and then the recipient would use that fulfillment to fulfill the initial packet (6)
Although it might need to be a higher number if it's meant to match the steps in the bidirectional flow section of the doc above
There was a problem hiding this comment.
I updated the images to make them more flow-based (27b710b) - take another look?
|
|
||
| This protocol is not designed to debug routing issues and does not provide additional diagnostic information about the state of routing. That use case would be better served by a separate `traceroute` mechanism. | ||
|
|
||
| All Interledger implementations _SHOULD_ respond to ping protocol requests, unless a node has a specific reason not to, such as security or privacy concerns. |
There was a problem hiding this comment.
can we clarify implementation here? Is a STREAM server expected to respond to pings, or just connectors?
There was a problem hiding this comment.
hmmm...great question. I'm not sure I have a strong opinion. In Java-land, we've moved most of our receiver logic into the Connector runtime, so this deployment style would sort of get ping functionality for free because it's all running in the connector. Though you sort of have to know the connector operator address to make it work.
I suppose after re-reading line 15 above, it's sort of optional for a STREAM receiver to support this functionality -- maybe that's enough?
Signed-off-by: sappenin <[email protected]>
Thanks that makes sense. |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. If this issue is important, please feel free to bring it up on the next Interledger Community Group Call or in the Gitter chat. |
This PR has been dormant for a very long time, but I'm reintroducing it for a few reasons:
Links for Context