Ivan,
Considering that the setting controls the way a communication SPI
connection is open I would add the new parameter to CommunicationSpi
interface naming it as follows:
>
> CommunicationSpi.connectionInitiationMode
> {
> BIDIRECTIONAL, //both clients and servers initiate a connection
> initiation procedure
> CLIENTS_TO_SERVERS //servers cannot open a connection to clients, only
> clients can do that
> }
The problem with the environment type approach is that private networks of
bare-metal environments usually impose restrictions similar to virtual
environments powered by Kubernetes. Thus, environmentType.VIRTUALIZED
doesn't cover all the cases and I'm struggling to come up with a universal
alternative.
-
Denis
On Thu, May 21, 2020 at 5:38 AM Ivan Bessonov <bessonov...@gmail.com> wrote:
> Hello Igniters,
>
> I'd like to discuss with you changes related to [1] and [2]. Both issues
> are mostly the same so
> let's discuss the core idea.
>
> *Motivation.*
>
> There are certain environments that don't allow Ignite server nodes to open
> TCP connections to
> thick clients, e.g. K8S, AWS Lambda or Azure Functions. To operate in such
> environments, the
> server needs a way to request a client to open an "inverse" communication
> connection to it.
>
> I've prepared a PR (still in progress) that introduces new mechanism of
> opening connection and
> related configuration.
>
> *Main idea*
>
> This mechanism is called "communication via discovery" or "inverse
> connection", it works as
> follows:
> - server that needs to connect to "unreachable" thick client sends a
> specific Discovery message
> (inverse communication request) to that client;
> - client node upon receiving the request opens communication connection to
> that server;
> - server sees connection opened by client and proceeds with its task (that
> required opening
> connection to the client).
>
> Working name for new configuration parameter for this feature is
> environmentType, it is an
> enum with two values (again, working names): STANDALONE (default) and
> VIRTUALIZED.
> It is used as a hint to server to speed-up establishing of connections:
> when server sees a client
> with VIRTUALIZED environmentType it doesn't try to open connection to it
> and sends inverse
> communication request right away.
> If environmentType is STANDALONE then server tries to open a connection in
> a regular way
> (iterating over all client addresses) and sends request only if all
> attempts failed.
>
> There is a concern about naming of the configuration as it catches only one
> use-case: when we
> deal with some kind of virtualized environment like K8S.
> There are other options I've encountered in private discussion:
> - connectionMode - ALWAYS_INITIATE / INITIATE_OR_ACCEPT
> - networkConnectivity - REACHABLE_ALWAYS / REACHABLE_ONE_WAY
> - communicationViaDiscovery - ALWAYS / FALLBACK
> - isReachableFromAllNodes (true/false flag)
> - initiateConnectionsOnThisNode (true/false flag).
>
> *Limitations*
>
> The feature cannot be used along with pairedConnection setting as this
> setting implies
> establishing connections in both directions. Also current implementation
> supports opening only
> client-to-server connections. Other types of connections like
> client-to-client or server-to-server
> will be implemented in separate tickets.
>
> [1] https://issues.apache.org/jira/browse/IGNITE-12438
> [2] https://issues.apache.org/jira/browse/IGNITE-13013
>
> --
> Sincerely yours,
> Ivan Bessonov
>
