Igor, ok, agreed.
On Mon, Jun 27, 2022 at 11:27 PM Igor Sapego wrote:
> 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
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 wrote:
> Thanks for the answers, Igor.
>
> On Thu, May 19, 2022 at
Thanks for the answers, Igor.
On Thu, May 19, 2022 at 10:55 PM Igor Sapego 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
One more corner case:
In case of a connection loss, even if the message was successfully written
to the socket, there is no guarantee it was read on the other side
For example, a client could have sent a request with ID 10, but the server
did not get it.
Or the server sent a reply to request 9,
Another point:
With the current proposal, there is no way for the server to distinguish
a broken connection from a normal user-initiated connection close.
So in either case we'll wait for some configured timeout before cleaning up
session resources.
I think this is fine, at least for now.
On
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.
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
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 wrote:
> Igor,
>
> Thanks for the proposal.
>
> I understand that such a situation is
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
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
wrote:
> Igor,
>
> The proposal looks good to me. Very
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
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:
12 matches
Mail list logo
