[
https://issues.apache.org/jira/browse/IGNITE-13986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17267364#comment-17267364
]
Ivan Bessonov commented on IGNITE-13986:
----------------------------------------
Ok, now the same thing but with a new context. Following thought might go into
IEP in the future.
New component will conceptually include group membership and p2p messaging
subsystem. It's going to be a general network component. Required API consists
of the following:
* start / stop;
* retrieving information about current group members;
* listening to membership events:
** node appeared;
** node left;
** node failed;
* listening for incoming messages;
* sending messages:
** there's a requirements of being able to send idempotent messages with very
weak guarantees:
*** no delivery guarantees required;
*** multiple copies of the same message might be sent;
*** no need to have any kind of acknowledgement;
** there's another requirement for the common use:
*** message must be sent exactly once with an acknowledgement that it has
actually been received (not processed);
*** messages must be received in the same order they were sent.
These types of messages might utilize current recovery protocol with acks every
32 (or so) messages. This setting must be flexible enough so that we won't get
OOM in big topologies.
Possibility of SSL connections should be considered.
Given that SWIM membership events appear in no particular order, it's possible
to receive a message from node before knowing that it exists or after it's
already gone. This is one of the reasons why we should basically merge
"discovery" and "communication" into one thing. Another reason is that it's
more convenient to use a single port per node instead of two (i.e. use
multiplexing).
There might be a requirement to stream data from one node to another (in SQL
engine, for example). The implementation is not obvious for me, maybe such
thing will be implemented on top of the current component. Anyway,
implementation will be tightly coupled with netty integration, currently
investigated by [~sergeychugunov].
Everything related to actual "Discovery" and messages like "NodeJoined" is not
discussed here. Since we're moving to RAFT-based distributed metadata storage
as a mean to send ordered messages, discussing them is just out of scope.
Current "Discovery" with its join protocol and strict ordering of events will
cease to exist.
There's a bunch of settings that should be extracted from scalecube
configuration and joined with some specific netty settings. The whole set of
settings will be determined during implementation. New configuration framework
will be used. For the first time, probably.
> Proof of concept - SWIM group membership protocol for discovery
> ---------------------------------------------------------------
>
> Key: IGNITE-13986
> URL: https://issues.apache.org/jira/browse/IGNITE-13986
> Project: Ignite
> Issue Type: New Feature
> Reporter: Ivan Bessonov
> Assignee: Ivan Bessonov
> Priority: Major
> Labels: iep-61, ignite-3
>
> In IEP-61 it is mentioned that discovery protocol will be updated. We need to
> play with mentioned options for a little bit to conclude if they match our
> needs:
> [http://www.cs.cornell.edu/Info/Projects/Spinglass/public_pdfs/SWIM.pdf]
> [https://github.com/scalecube/scalecube-cluster]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
