anchor.diff:  [[rsocket-protocol]]
   === The Protocol
   
  -One of the benefits of RSocket is that it has a well defined behavior on the wire and an
  +One of the benefits of RSocket is that it has well defined behavior on the wire and an
   easy to read https://rsocket.io/docs/Protocol[specification] along with some protocol
   https://github.com/rsocket/rsocket/tree/master/Extensions[extensions]. Therefore it is
   a good idea to read the spec, independent of language implementations and higher level
  
positive.code: CBOR/JSON, and Protobuf that RSocket applications will likely need. It also contains the
  `PathPatternParser` that can be plugged in for efficient route matching.
  
  Spring Security...
  
  Spring Boot...
  
  
  
  
  
negative.code: Once the initial connection is made, the "client" vs "server" distinction is lost as
  both sides become symmetrical and each side can initiate one of the above interactions.
  This is why in the protocol calls the participating sides "requester" and "responder"
  while the above interactions are called "request streams" or simply "requests".
  
  These are the key features and benefits of the RSocket protocol:
  
  * https://www.reactive-streams.org/[Reactive Streams] semantics across network boundary --
  for streaming requests such as `Request-Stream` and `Channel`, back pressure signals
  travel between requester and responder, allowing a requester to slow down a responder at
  the source, hence reducing reliance on network layer congestion control, and the need
  for buffering at the network level or at any level.
  * Request throttling -- this feature is named "Leasing" after the `LEASE` frame that
  can be sent from each end to limit the total number of requests allowed by other end
  for a given time. Leases are renewed periodically.
  * Session resumption -- this is designed for loss of connectivity and requires some state
  