On Mon, Nov 23, 2020 at 7:32 AM Petrenko, Vadim <vadim.petre...@ns.nl> wrote:
> Thank you guys for your responses. > > What bothers me is that such an Edge router placed at the client will have > all the topology information about every single other router in the > network, how they are interconnected, etc., as it has to participate in the > routing data exchange. It will even expose the Qpid console! Will show > network throughput, etc. Some data a client should have no access to imo. > > Some of these clients in our case might have intermittent connections over > weak links, and there could be quite a few of them (i.e. several thousands > clients). So this routing information would have to be exchanged every time > a client's Edge router connects to the core network. > > Do you have any ideas how to mitigate this or maybe this shouldn't > actually deserve any serious concerns? > > Actually, the edge routers do not fully participate in the route table exchange. Edge routers are exposed to only those addresses needed by the clients attached to the edge itself. Specifically, when a subscriber client attaches to the edge, the edge notifies its attached interior router of the subscription address and leaves it to the interior router to propagate that on behalf of the edge router. Similar behavior for producing clients - the edge queries its interior router for route details for only the producer's destination address. So the amount of routing information that needs to be exchanged between the edge and its interior is minimal and probably is not something to be concerned about. -K > Thank you. > > -----Original Message----- > From: Chuck Rolke <cro...@redhat.com> > Sent: vrijdag 20 november 2020 17:57 > To: users@qpid.apache.org > Subject: Re: Edge router on the client side > > Also, do not build the image with certificates embedded within it. > Find a way to inject the connection secrets into the container as it is > launched. > > > ----- Original Message ----- > > From: "Ted Ross" <tr...@redhat.com> > > To: users@qpid.apache.org > > Sent: Friday, November 20, 2020 10:53:45 AM > > Subject: Re: Edge router on the client side > > > > On Fri, Nov 20, 2020 at 5:32 AM Petrenko, Vadim <vadim.petre...@ns.nl> > > wrote: > > > > > Hi Qpid developers, > > > > > > We’re considering this possibility: > > > > > > Containerize a preconfigured Edge router (possibly together with > Artemis) > > > and give it to an application team. > > > > > > The application team will then deploy this container in their > environment > > > -> the Edge router will connect to a couple Interior routers in our > Core > > > network -> the client application will connect to the Edge router in > the > > > container using standard libraries like Qpid-JMS. > > > > > > We expect this to allow easy scaling up of clients. We also want to > attach > > > a broker to the edge router in case messages need to be buffered (but > this > > > is client specific and does not belong to the generic core network > setup). > > > > > > Does this setup look reasonable from a Qpid developer’s point of view? > > > Maybe there are some pitfalls to watch out for? Especially exposing > > > Interior routers to the world. > > > > > > > This is a good use case, and one that I think is appropriate for edge > > routers. > > > > If you are going to deploy your interior routers in a public place, I > think > > you would want strong security (mutual TLS) on those open ports. Can you > > issue certificates to your application teams in the form of secrets so > they > > can securely connect to your network? > > > > > > > > > > > > > Thanks! > > > > > > > > > > > > ________________________________ > > > > > > Deze e-mail, inclusief eventuele bijlagen, is uitsluitend bestemd voor > > > (gebruik door) de geadresseerde. De e-mail kan persoonlijke of > > > vertrouwelijke informatie bevatten. Openbaarmaking, vermenigvuldiging, > > > verspreiding en/of verstrekking van (de inhoud van) deze e-mail (en > > > eventuele bijlagen) aan derden is uitdrukkelijk niet toegestaan. > Indien u > > > niet de bedoelde geadresseerde bent, wordt u vriendelijk verzocht > degene > > > die de e-mail verzond hiervan direct op de hoogte te brengen en de > e-mail > > > (en eventuele bijlagen) te vernietigen. > > > > > > Informatie vennootschap<http://www.ns.nl/emaildisclaimer> > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > > > For additional commands, e-mail: users-h...@qpid.apache.org > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > > > ________________________________ > > Deze e-mail, inclusief eventuele bijlagen, is uitsluitend bestemd voor > (gebruik door) de geadresseerde. De e-mail kan persoonlijke of > vertrouwelijke informatie bevatten. Openbaarmaking, vermenigvuldiging, > verspreiding en/of verstrekking van (de inhoud van) deze e-mail (en > eventuele bijlagen) aan derden is uitdrukkelijk niet toegestaan. Indien u > niet de bedoelde geadresseerde bent, wordt u vriendelijk verzocht degene > die de e-mail verzond hiervan direct op de hoogte te brengen en de e-mail > (en eventuele bijlagen) te vernietigen. > > Informatie vennootschap<http://www.ns.nl/emaildisclaimer> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > > -- -K
