> On Jun 30, 2017, at 4:39 PM, Matteo Merli <matteo.me...@gmail.com> wrote: > > On Fri, Jun 30, 2017 at 12:41 PM, Dave Fisher <dave2w...@comcast.net> wrote: > >> So I am clear the problem is having an SSL endpoint that authenticates the >> client and allows the messages to flow through to the correct broker. >> > > > The main problem this proposal is trying to solve is how to expose Pulsar, > which is a stateful service [1], through a stateless frontend.
One thought is make the proxy into a WebSocket frontend but then pass through to the broker using the TCP protocol. WebSocket would fit a pattern that everyone is used to scaling. It could be setup through Tomcat with connections through a VIP. Think about it. > The reason to have a stateless frontend, is that it's much easier to give > access to this service from outside the current cluster/datacenter. If you > have a stateless service, you can easily use multiple strategies (VIP, DNS, > ....) to expose multiple instances that are composing the service and you > don't need to connect to specific nodes. Any node, as routed by the > VIP/DNS/.. mechanism will work. > > One example of this is when deploying in a cloud environment, especially > with some container orchestration mechanism like kubernetes. If you want to > connect and publish messages from outside the Kubernetes cluster (or from > outside the cloud region alltogether), having the stateless service, > exposed to a cloud specific load balancer, makes it a lot easier to deploy > and to control the access from the outside world. Yes and this could work with WebSocket. > > For the SSL part, right now in Pulsar you might want to use TLS/SSL for few > reasons: > 1. Transport encryption > 2. Broker authentication (validate the broker we're talking to is > legitimate) > 3. Client authentication (extract the client principal to be used for > authorization) > > All these 3 should continue to work even when a proxy is introduced. In > particular, for the client authentication, the proxy is responsible of > validating the authentication and then carry the client principal over to > the broker. > > >>> Can I assume that if the broker disconnects that the requirement is for > the client to reconnect and then at that point get the new broker? > > Correct, that's the behavior of the client library and it will not change. > Whenever the connection breaks, the client library internally tries to > re-do the topic lookup (because now it might have moved to a different > broker) and reconnect, with exponential backoff, until it succeeds. > > > [1] brokers don't keep state on disk, but still a topic is only assign to > a single broker at a give point in time. > Great. Regards, Dave > > -- > Matteo Merli > <matteo.me...@gmail.com>
signature.asc
Description: Message signed with OpenPGP
