[infinispan-dev] Single Endpoint design

Thu Apr 6 05:31:46 EDT 2017

The design has been moved here:
https://github.com/infinispan/infinispan-designs/pull/2

Are there any last comments? I plan to start working on that shortly.

Thanks,
Sebastian

On Fri, Mar 31, 2017 at 4:20 PM Sebastian Laskawiec <slaskawi at redhat.com>
wrote:

> With TLS+ALPN the use case is very simple. The protocol is negotiated
> during the handshake. Then the existing TCP connection is reused and the
> client starts to send Hot Rod binary bits through the wire. Sadly, TLS adds
> some significant overhead to the transmission.
>
> With HTTP/1.1 Upgrade it's a bit more complicated. The Upgrade request
> might issued by the client as well as by the server. Each of the parties
> can ignore the request if it doesn't recognize it (or doesn't support
> protocols proposed by the other side). The more I think about this, the
> more I lean towards to server initiated upgrade requests. This way, only
> clients which supports the upgrade will react to it. It still needs some
> more thought...
>
> Of course you are right, some additional code will need to be added to the
> clients to support switching protocols. The good news is that you won't be
> forced to use the Single Endpoint. You may want to expose our old, good Hot
> Rod Endpoint and forget about all this switching complexity.
>
> Regarding to network hops - no, there is no additional network hops. The
> router component simply identifies the incoming request and plugs proper
> Netty Handler stack to it. Here's an example how it is done with
> multi-tenancy based on SNI [1].
>
> [1]
> https://github.com/infinispan/infinispan/blob/master/server/router/src/main/java/org/infinispan/server/router/router/impl/hotrod/handlers/SniRouteHandler.java#L48-L61
>
> On Fri, Mar 31, 2017 at 2:22 PM Tristan Tarrant <ttarrant at redhat.com>
> wrote:
>
> No, once the connection is established, I believe the netty pipeline can
> be trimmed to the necessary elements.
>
> Tristan
>
> On 31/03/2017 13:57, Gustavo Fernandes wrote:
> > On Fri, Mar 31, 2017 at 11:02 AM, Tristan Tarrant <ttarrant at redhat.com
> > <mailto:ttarrant at redhat.com>> wrote:
> >
> >     You understood incorrectly.
> >     The only change to the Hot Rod clients is that, if they get a 400
> error
> >     from a HR PING request, they will initiate an upgrade to Hot Rod and
> >     then proceed with the usual Hot Rod protocol after that.
> >
> >
> > Thanks for the clarification. Still, after the HR protocol is
> > negotiated, communication will go
> > through a router, thus adding an extra hop?
> >
> > Gustavo
> >
> >     Tristan
> >
> >     On 31/03/2017 11:58, Gustavo Fernandes wrote:
> >     > Hi Sebastian,
> >     >
> >     > If I understood it correctly, all the Hot Rod clients will be
> changed
> >     > from using:
> >     >
> >     > - Binary over TCP, circa 40 bytes header, no hops to contact the
> server,
> >     > no protocol negotiation, no encryption (default)
> >     >
> >     > to
> >     >
> >     > - HTTP/2 with SSL, protocol upgrade negotiation, and a hop
> (router) to
> >     > connect to the server.
> >     >
> >     >
> >     > Any idea of how significant would be this extra overhead
> introduced?
> >     >
> >     >
> >     > Thanks,
> >     > Gustavo
> >     >
> >     >
> >     > On Thu, Mar 30, 2017 at 2:01 PM, Sebastian Laskawiec
> >      > <slaskawi at redhat.com <mailto:slaskawi at redhat.com>
> >     <mailto:slaskawi at redhat.com <mailto:slaskawi at redhat.com>>> wrote:
> >      >
> >      >     Hey!
> >      >
> >      >     My plan is to start working on a Single Point support for
> >     Infinispan
> >      >     Server very soon and I prepared a design:
> >      > https://github.com/infinispan/infinispan/pull/5041
> >     <https://github.com/infinispan/infinispan/pull/5041>
> >      >     <https://github.com/infinispan/infinispan/pull/5041
> >     <https://github.com/infinispan/infinispan/pull/5041>>
> >      >
> >      >     As you can see I did not use our Wiki (as we used to) because
> it
> >      >     doesn't support inline comments (which is pretty bad in my
> >     opinion).
> >      >     I would like to propose to keep all the designs along with our
> >      >     source code. This approach has been successfully used by the
> >      >     Kubernetes [1] folks (although they migrated designs into the
> new
> >      >     Community repository [2] recently). I think it might be a
> >     good idea
> >      >     to do something similar.
> >      >
> >      >     Feedback on both items is more than welcome.
> >      >
> >      >     Thanks,
> >      >     Sebastian
> >      >
> >      >     [1]
> >      >
> >     https://github.com/kubernetes/kubernetes/tree/master/docs/proposals
> >     <https://github.com/kubernetes/kubernetes/tree/master/docs/proposals
> >
> >      >
> >       <
> https://github.com/kubernetes/kubernetes/tree/master/docs/proposals <
> https://github.com/kubernetes/kubernetes/tree/master/docs/proposals>>
> >      >     [2]
> >      >
> >
> https://github.com/kubernetes/community/tree/master/contributors/design-proposals
> >     <
> https://github.com/kubernetes/community/tree/master/contributors/design-proposals
> >
> >      >
> >       <
> https://github.com/kubernetes/community/tree/master/contributors/design-proposals
> <
> https://github.com/kubernetes/community/tree/master/contributors/design-proposals
> >>
> >      >
> >      >     _______________________________________________
> >      >     infinispan-dev mailing list
> >      > infinispan-dev at lists.jboss.org
> >     <mailto:infinispan-dev at lists.jboss.org>
> >     <mailto:infinispan-dev at lists.jboss.org
> >     <mailto:infinispan-dev at lists.jboss.org>>
> >      > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >     <https://lists.jboss.org/mailman/listinfo/infinispan-dev>
> >      >     <https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >     <https://lists.jboss.org/mailman/listinfo/infinispan-dev>>
> >     >
> >     >
> >     >
> >     >
> >     > _______________________________________________
> >     > infinispan-dev mailing list
> >     > infinispan-dev at lists.jboss.org <mailto:
> infinispan-dev at lists.jboss.org>
> >     > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >     <https://lists.jboss.org/mailman/listinfo/infinispan-dev>
> >     >
> >
> >     --
> >     Tristan Tarrant
> >     Infinispan Lead
> >     JBoss, a division of Red Hat
> >     _______________________________________________
> >     infinispan-dev mailing list
> >     infinispan-dev at lists.jboss.org <mailto:
> infinispan-dev at lists.jboss.org>
> >     https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >     <https://lists.jboss.org/mailman/listinfo/infinispan-dev>
> >
> >
> >
> >
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >
>
> --
> Tristan Tarrant
> Infinispan Lead
> JBoss, a division of Red Hat
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --

SEBASTIAN ŁASKAWIEC

INFINISPAN DEVELOPER

Red Hat EMEA <https://www.redhat.com/>
<https://red.ht/sig>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170406/f6abb1b4/attachment-0001.html 