[infinispan-dev] Single Endpoint design

Sebastian Laskawiec slaskawi at redhat.com
Fri Mar 31 10:20:03 EDT 2017


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170331/6eae9376/attachment-0001.html 


More information about the infinispan-dev mailing list