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
