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.

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.

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.


--
Matteo Merli
<matteo.me...@gmail.com>

Reply via email to