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 > > >
