Sorry for me being obnoxious here, but still. Mentioning ticket numbers
usually does not make a lot of sense for someone, who is outside of context
of popular/trendy tickets.
At the same time, usually contributors scan emails in the list using
subject. They decide what should go to archive and what should they read.
So, in future it may worth to replace all numbers with tickets' actual
topic/summary. People are still humans and they may be too lazy to open
tickets to decide if they need to read this topic or not.
пт, 22 мая 2020 г. в 02:48, Valentin Kulichenko <
valentin.kuliche...@gmail.com>:
> Ivan,
>
> Have you considered eliminating server to client connections altogether?
> Or, at the very least making the "client to server only" mode the default
> one?
>
> All the suggested names are confusing and not intuitive, and I doubt we
> will be able to find a good one. A server initiating a TCP connection with
> a client is confusing in the first place and creates a usability issue. We
> now want to solve it by introducing an additional configuration
> parameter, and therefore additional complexity. I don't think this is the
> right approach.
>
> What are the drawbacks of permanently switching to client-to-server
> connections? Is there any value provided by the server-to-client option?
>
> As for pair connections, I'm not sure I understand why there is a
> limitation. As far as I know, the idea behind this feature is that we
> maintain two connections between two nodes instead of one, so that every
> connection is used for communication in a single direction only. Why does
> it matter which node initiates the connection? Why can't one of the nodes
> (e.g., a client) initiate both connections, and then use them accordingly?
> Correct me if I'm wrong, but I don't see why we can't do this.
>
> -Val
>
> On Thu, May 21, 2020 at 1:58 PM Denis Magda <dma...@apache.org> wrote:
>
> > 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
> > >
> >
>
