Andrey, > different connections on different client instances theoretically > could generate an already existing connection ID
Do you mean an UUID collision? On Thu, May 19, 2022 at 1:09 AM Andrey Gura <ag...@apache.org> wrote: > Igor, > > Thanks for the proposal. > > I understand that such a situation is almost impossible but "if > anything can go wrong, it will". Does the protocol take into account > that different connections on different client instances theoretically > could generate an already existing connection ID? > > Also, do I understand correctly that a server has enough information > about client connections so it will be possible to observe a > connections list on the server? It would be useful for cluster > monitoring purposes. > > On Tue, May 17, 2022 at 3:11 PM Igor Sapego <isap...@apache.org> wrote: > > > > 1. I've tried to clarify IDs part; > > 2. Maybe you are right, though in this case we'd need to use > authentication > > in ConnectionRestoreReq. Which sounds reasonable to me. > > > > Best Regards, > > Igor > > > > > > On Tue, May 17, 2022 at 10:47 AM Pavel Tupitsyn <ptupit...@apache.org> > > wrote: > > > > > Igor, > > > > > > The proposal looks good to me. Very detailed! > > > > > > A couple comments: > > > > > > 1. There is a bit of a term mixup with "Connection ID", "Node ID", > "Token" > > > - can you please review those? > > > > > > 2. > The Connection ID should be generated using a proper secure > algorithm > > > (additional research is required here) to make sure an intruder can not > > > generate an existing Connection ID > > > Not sure about the reasoning here. I think randomUUID() should be > enough: > > > - In the case of an unsecured cluster it does not matter, because > anyone > > > can do anything. > > > - In the case of a secured cluster it does not matter, because > > > authentication/authorization keeps intruders out. > > > > > > > > > On Mon, May 16, 2022 at 11:07 PM Igor Sapego <isap...@apache.org> > wrote: > > > > > > > Hi, Igniters > > > > > > > > I've prepared an IEP for Ignite 3 Client Lifecycle [1]. The main > idea is > > > to > > > > define client lifecycle as well as core algorithms and mechanisms > used by > > > > clients. This proposal can be used as a reference for implementation > of a > > > > new client for Ignite when dealing with such problems as: > > > > > > > > - Resolving of user-provided addresses; > > > > - Initial connection to a cluster; > > > > - Maintaining cluster connection; > > > > - Connection recovery; > > > > - Connection break handling. > > > > > > > > So take a look and let me know what you think guys. > > > > > > > > [1] - > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-90+Client+Lifecycle > > > > > > > > Best Regards, > > > > Igor > > > > > > > >
