Pavel, let's postpone developing a sessions part until all the corner cases are clarified. I'll let you know when new the proposal is ready for discussion again.
Best Regards, Igor On Mon, May 23, 2022 at 12:25 PM Andrey Gura <ag...@apache.org> wrote: > Thanks for the answers, Igor. > > On Thu, May 19, 2022 at 10:55 PM Igor Sapego <isap...@apache.org> wrote: > > > > Andrey, > > > > 1. If a server generates a UUID that already exists it can check and just > > re-generate it straight away > > as a check is just a simple map lookup. > > > > 2. Well, yes. This proposal does not consider monitoring, but with > current > > approach it will be definitely > > easier to implement it properly. > > > > Pavel, > > > > Wow, that's really cool that you've already started working on it. > > > > Regarding your proposal I like it - it will really make a procedure > easier > > and faster for a client. I'll change > > the IEP accordingly. > > > > Best Regards, > > Igor > > > > > > On Thu, May 19, 2022 at 11:40 PM Pavel Tupitsyn <ptupit...@apache.org> > > wrote: > > > > > Igor, > > > > > > I've started working on the initial sessions implementation [1], > > > and I'd like to clarify the procedure of logical connection restore. > > > > > > > client in its turn tries to establish a new *node connection* > > > > and restore *logical connection *using ConnectionRestoreReq > > > > > > This implies either an additional request, or something that replaces > > > normal handshake. > > > However, we need to handle two cases here: > > > - Logical connection is restored > > > - Logical connection is not restored (timed out, server restarted, > etc), in > > > which case we still establish the connection and use it. > > > > > > To account for the second case, we should always start with a regular > > > handshake. > > > I propose to add a nullable UUID field to the handshake request to > cover > > > both cases: > > > - connectionId is null or not found on server: proceed with normal > > > handshake, return newly generated connectionId. > > > - connectionId is not null and found on server: restore logical > connection, > > > return the same connectionId > > > > > > Client checks if returned connectionId equals to the original and > > > understands whether logical connection was restored or not. > > > > > > Thoughts? > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-16928 > > > > > > On Thu, May 19, 2022 at 10:27 PM Pavel Tupitsyn <ptupit...@apache.org> > > > wrote: > > > > > > > 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 > > > >> > > > > > > >> > > > > > >> > > > > > > > >
