1

I recently wrote a protocol I call RPEP (https://github.com/Tixit/RPEP), partially in response to the unfortunately named WAMP protocol. I'm looking for feedback as to whether the protocol is specified completely enough.

In particular, I'm wondering if my specification about connection establishment and closure is specific enough for implementers to know how to properly implement that section:

Implementations must provide some way for a peer to indicate that a connection 
has been established and that the connection will be closed. One of two ways 
of doing this must be available:

* Some transport-protocol-level message, or
* An RPEP "close" Fire and Forget message of the form ["close", closeData]

Implementations are required to use the implemented way of information the 
other Peer of connection establishment. Implementations are, on the other 
hand, NOT required to use the implemented way to inform the other Peer of 
connection closure, ie it is allowed to drop a connection without informing 
the other Peer. But to reiterate, a method of closure that does involve 
informing the other Peer must be implemented.

Is that section specific enough for implementers?

Please keep your answers to the point of protocol completeness. If you have other comments, questions, or advice, feel free to create an issue on the github repository for it, rather than writing an answer or comment here.

B T
  • 340
  • 2
  • 9

1 Answers1

1

I do not know what RPEP in detail is. This is a good starting point for this question.

I imagine taking your library and programming my own communication mechanism, based on your protocol description.

Here is what I understand:

  • The situation is: two partners are in an established communication, and it is now about closing.
  • In order to stick to your protocol, I am allowed to drop the communication immediately without any comment. That's fine, I am not breaking rules.
  • If I want to close the connection not immediately and inform the communication partner, then I must either send a RPEP close message that is "fire and forget", or I must send a transport-protocol-level message.

I would now lookup the RPEP close message, its syntax and whatnot. The "fire and forget" tells me that once I have sent the close message, I should not expect some confirmation, i.e. I should not write my code that way it expects a confirmation.

I am not sure about "transport-protocol"... is this the TCP domain? -

You may now evaluate what I got wrong. I hope this is helping.

As an addendum:

  • What about communication recovery after a accidentally interruption? Should it become clear from your text?
  • There's a typo: 3rd paragraph, first sentence: "Implementations are required to use the implemented way of inform_ING_..."
peter_the_oak
  • 661
  • 3
  • 8
  • Looks like you mostly got it. Some of the things you asked questions about are in the full spec, so I'm not worried about those. The transport protocol could be TCP modified for message chunking or websockets. Also thanks for the typo note. You asked about communication recovery: what kind of accidental interruption are you talking about? My first thought is that the underlying transport protocol used should be the one to worry about that kind of thing. – B T Mar 01 '16 at 18:58
  • 1
    @BT, I'm glad to hear your description works out. About the communication recovery: due to your comment, I understand your intention better. I see that my thoughts are leading towards the fundamentals of stateless or stateful protocols and the principles of protocol security. Like you mentioned in your OP, there would be better places to discuss. For now, I say it's just fine :-) – peter_the_oak Mar 02 '16 at 08:09
  • Feel free to discuss on github : ) – B T Mar 02 '16 at 08:24