Merge pull request nanomsg#370 from rzezeski/req-rep-rfc-enhancements

Enhancements to the request-reply SP RFC

rfc/sp-request-reply-01.txt

@@ -295,7 +295,7 @@ Internet-Draft              Request/Reply SP                 August 2013
    As for delivering replies back to the clients, it should be
    understood that the client may not be directly accessible (say using
    TCP/IP) from the processing node.  It may be beyond a firewall, have
-   no static IP address etc. Furthermore, the client and the processing
+   no static IP address etc.  Furthermore, the client and the processing
    may not even speak the same transport protocol -- imagine client
    connecting to the topology using WebSockets and processing node via
    SCTP.
@@ -326,7 +326,7 @@ Internet-Draft              Request/Reply SP                 August 2013
    immediately after it is started.  Given that some nodes in the
    topology may be extremely short-lived this is a crucial requirement.
    Imagine a database client that sends a query, reads the result and
-   terminates.  It makes no sense to delay the whole process till the
+   terminates.  It makes no sense to delay the whole process until the
    routing tables are synchronised between the client and the server.
 
 
@@ -518,7 +518,7 @@ Internet-Draft              Request/Reply SP                 August 2013
    down the client application, i.e. it prevents the user from sending
    any more requests.
 
-   If the channel is not capable of reporting backpressure (e.g. DCCP)
+   If the channel is not capable of reporting backpressure (e.g.  DCCP)
    the endpoint SHOULD consider it as always available for sending new
    request.  However, such channels should be used with care as when the
    congestion hits they may suck in a lot of requests just to discard
@@ -551,7 +551,7 @@ Internet-Draft              Request/Reply SP                 August 2013
 
    As for incoming messages, i.e. replies, REQ endpoint MUST fair-queues
    them.  In other words, if there are replies available on several
-   channels, it MUST receive them in a round-robin fashion.  It mast
+   channels, it MUST receive them in a round-robin fashion.  It must
    also take care not to compromise the fairness when new channels are
    added or old ones removed.
 
@@ -640,14 +640,12 @@ Internet-Draft              Request/Reply SP                 August 2013
    resent, however, it doesn't really matter because there's no one to
    deliver the reply to any more anyway.
 
-   Also note that unlike with the requests there's no pushback applied
-   to the replies.  The replies are simply dropped in the case of
-   pushback.  The reason for this behaviour is that if the endpoint
-   blocked and waited for the channel be become available, all the
-   subsequent replies, possibly destined for different, unblocked
-   channels would be blocked in the meantime anyway.  That would allow
-   for a DoS attack by simply firing a lot of requests and not receiving
-   the replies.
+   Unlike requests, there's no pushback applied to the replies; they are
+   simply dropped.  If the endpoint blocked and waited for the channel
+   to become available, all the subsequent replies, possibly destined
+   for different unblocked channels, would be blocked in the meantime.
+   That allows for a DoS attack simply by firing a lot of requests and
+   not receiving the replies.
 
 6.  End-to-end functionality
 
@@ -665,6 +663,8 @@ Internet-Draft              Request/Reply SP                 August 2013
 
    To be able to do the latter, the endpoint must tag the requests with
    unique 31-bit request IDs.  First request ID is picked at random.
+   All subsequent request IDs are generated by adding 1 to the last
+   request ID and possibly overflowing to 0.
 
 
 
@@ -674,9 +674,6 @@ Sustrik                 Expires February 2, 2014               [Page 12]
 Internet-Draft              Request/Reply SP                 August 2013
 
 
-   All subsequent request IDs are generated by adding 1 to the last
-   request ID and possibly overflowing to 0.
-
    To improve robustness of the system, the implementation MUST ensure
    that the random number is different each time the endpoint, the
    process or the machine is restarted.  Pseudo-random generator with
@@ -722,6 +719,9 @@ Internet-Draft              Request/Reply SP                 August 2013
 
    Finally, REQ endpoint MUST make it possible for the user to cancel a
    particular request in progress.  What it means technically is
+   deleting the stored copy of the request and cancelling the associated
+   timer.  Thus, once the reply arrives, it will be discarded by the
+   algorithm above.
 
 
 
@@ -730,10 +730,6 @@ Sustrik                 Expires February 2, 2014               [Page 13]
 Internet-Draft              Request/Reply SP                 August 2013
 
 
-   deleting the stored copy of the request and cancelling the associated
-   timer.  Thus, once the reply arrives, it will be discarded by the
-   algorithm above.
-
    The cancellation allows, for example, the user to time out a request.
    They can simply post a request and if there's no answer in specific
    timeframe, they can cancel it.
@@ -755,8 +751,8 @@ Internet-Draft              Request/Reply SP                 August 2013
    is reached without finding the bottom of the stack, the request is
    malformed and MUST be ignored.
 
-   Note that the payload payload produced by this procedure is the same
-   as the request payload sent by the original client.
+   Note that the payload produced by this procedure is the same as the
+   request payload sent by the original client.
 
    Once the user processes the request and sends the reply, the endpoint
    prepends the reply with the stored traceback stack and sends it on
@@ -777,7 +773,11 @@ Internet-Draft              Request/Reply SP                 August 2013
    specific error massage back to the client it can do so by not
    cancelling the request and sending a regular reply.
 
+7.  Loop avoidance
 
+   It may happen that a request/reply topology contains a loop.  It
+   becomes increasingly likely as the topology grows out of scope of a
+   single organisation and there are multiple administrators involved in
 
 
 
@@ -786,11 +786,6 @@ Sustrik                 Expires February 2, 2014               [Page 14]
 Internet-Draft              Request/Reply SP                 August 2013
 
 
-7.  Loop avoidance
-
-   It may happen that a request/reply topology contains a loop.  It
-   becomes increasingly likely as the topology grows out of scope of a
-   single organisation and there are multiple administrators involved in
    maintaining it.  Unfortunate interaction between two perfectly
    legitimate setups can cause loop to be created.
 
@@ -837,5 +832,9 @@ Author's Address
 
 
 
-Sustrik                 Expires February 2, 2014               [Page 15]
 
+
+
+
+
+Sustrik                 Expires February 2, 2014               [Page 15]

rfc/sp-request-reply-01.xml

@@ -285,7 +285,7 @@
          immediately after it is started. Given that some nodes in the topology
          may be extremely short-lived this is a crucial requirement. Imagine
          a database client that sends a query, reads the result and terminates.
-         It makes no sense to delay the whole process till the routing tables
+         It makes no sense to delay the whole process until the routing tables
          are synchronised between the client and the server.</t>
 
       <t>The algorithm thus works as follows: When request is routed from the
@@ -486,7 +486,7 @@
 
         <t>As for incoming messages, i.e. replies, REQ endpoint MUST fair-queues
            them. In other words, if there are replies available on several
-           channels, it MUST receive them in a round-robin fashion. It mast also
+           channels, it MUST receive them in a round-robin fashion. It must also
            take care not to compromise the fairness when new channels are
            added or old ones removed.</t>
 
@@ -564,14 +564,12 @@
            resent, however, it doesn't really matter because there's no one to
            deliver the reply to any more anyway.</t>
 
-        <t>Also note that unlike with the requests there's no pushback applied
-           to the replies. The replies are simply dropped in the case of
-           pushback. The reason for this behaviour is that if the endpoint
-           blocked and waited for the channel be become available, all the
-           subsequent replies, possibly destined for different, unblocked
-           channels would be blocked in the meantime anyway. That would allow
-           for a DoS attack by simply firing a lot of requests and not receiving
-           the replies.</t>
+        <t>Unlike requests, there's no pushback applied to the replies; they are
+           simply dropped. If the endpoint blocked and waited for the channel to
+           become available, all the subsequent replies, possibly destined for
+           different unblocked channels, would be blocked in the meantime. That
+           allows for a DoS attack simply by firing a lot of requests and not
+           receiving the replies.</t>
 
       </section>
 
@@ -669,8 +667,8 @@
            without finding the bottom of the stack, the request is malformed and
            MUST be ignored.</t>
 
-        <t>Note that the payload payload produced by this procedure is the same
-           as the request payload sent by the original client.</t>
+        <t>Note that the payload produced by this procedure is the same as the
+           request payload sent by the original client.</t>
 
         <t>Once the user processes the request and sends the reply, the endpoint
            prepends the reply with the stored traceback stack and sends it on