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 <slask...@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 <ttarr...@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 <ttarr...@redhat.com > > <mailto:ttarr...@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 > > > <slask...@redhat.com <mailto:slask...@redhat.com> > > <mailto:slask...@redhat.com <mailto:slask...@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@lists.jboss.org > > <mailto:infinispan-dev@lists.jboss.org> > > <mailto:infinispan-dev@lists.jboss.org > > <mailto:infinispan-dev@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@lists.jboss.org <mailto: > infinispan-dev@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@lists.jboss.org <mailto: > infinispan-dev@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@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@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>
_______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
