Do server nodes attempt to connect to client nodes?

classic Classic list List threaded Threaded
6 messages Options
javadevmtl javadevmtl
Reply | Threaded
Open this post in threaded view
|

Do server nodes attempt to connect to client nodes?

Hi, I have 3 server nodes deployed on VMs as far as they are concerned it's practically bare metal installation.

My client nodes CLIENT=TRUE connect from within DC/OS Cluster using docker in either bridged network or closed DC/OS network. I.e: They are not visible to the network.

In TCP/IP Discovery this seems to work no problem, client connects and I can do cache operations no problem.

But does the server node ever attempt to connect back to the client node in any way?
And do the clients need some kind special address resolution / port forwarding?

I see there's a BasicAddressResolver class, but it's not really documented in the official docs.
stephendarlington stephendarlington
Reply | Threaded
Open this post in threaded view
|

Re: Do server nodes attempt to connect to client nodes?

Yes, thick client nodes are peers, and so can both accept and initiate connections to and from other nodes.

It’s often easier to get a thin-client to work under these circumstances, as they behave in a more traditional client-server manner. Is that a viable option?

Regards,
Stephen

On 26 Jun 2020, at 16:28, John Smith <[hidden email]> wrote:

Hi, I have 3 server nodes deployed on VMs as far as they are concerned it's practically bare metal installation.

My client nodes CLIENT=TRUE connect from within DC/OS Cluster using docker in either bridged network or closed DC/OS network. I.e: They are not visible to the network.

In TCP/IP Discovery this seems to work no problem, client connects and I can do cache operations no problem.

But does the server node ever attempt to connect back to the client node in any way?
And do the clients need some kind special address resolution / port forwarding?

I see there's a BasicAddressResolver class, but it's not really documented in the official docs.


javadevmtl javadevmtl
Reply | Threaded
Open this post in threaded view
|

Re: Do server nodes attempt to connect to client nodes?

Good point. In some cases I use near cache. Maybe for the ones that don't need it, I can use the thin client.

I'm looking to see what port and I.Ps are made available to the container and see if I can set up address forwarding or whatever it's called.

On Fri, 26 Jun 2020 at 11:35, Stephen Darlington <[hidden email]> wrote:
Yes, thick client nodes are peers, and so can both accept and initiate connections to and from other nodes.

It’s often easier to get a thin-client to work under these circumstances, as they behave in a more traditional client-server manner. Is that a viable option?

Regards,
Stephen

On 26 Jun 2020, at 16:28, John Smith <[hidden email]> wrote:

Hi, I have 3 server nodes deployed on VMs as far as they are concerned it's practically bare metal installation.

My client nodes CLIENT=TRUE connect from within DC/OS Cluster using docker in either bridged network or closed DC/OS network. I.e: They are not visible to the network.

In TCP/IP Discovery this seems to work no problem, client connects and I can do cache operations no problem.

But does the server node ever attempt to connect back to the client node in any way?
And do the clients need some kind special address resolution / port forwarding?

I see there's a BasicAddressResolver class, but it's not really documented in the official docs.


dmagda dmagda
Reply | Threaded
Open this post in threaded view
|

Re: Do server nodes attempt to connect to client nodes?

John, Stephen,

Just for your reference, soon we'll introduce a configuration option that will prevent servers from initiating a connection with thick clients. The clients will be required to open the connection:

This configuration option is required for Kubernetes deployments and serverless applications and also useful for environments where servers and clients are separated with a NAT.

-
Denis


On Fri, Jun 26, 2020 at 9:35 AM John Smith <[hidden email]> wrote:
Good point. In some cases I use near cache. Maybe for the ones that don't need it, I can use the thin client.

I'm looking to see what port and I.Ps are made available to the container and see if I can set up address forwarding or whatever it's called.

On Fri, 26 Jun 2020 at 11:35, Stephen Darlington <[hidden email]> wrote:
Yes, thick client nodes are peers, and so can both accept and initiate connections to and from other nodes.

It’s often easier to get a thin-client to work under these circumstances, as they behave in a more traditional client-server manner. Is that a viable option?

Regards,
Stephen

On 26 Jun 2020, at 16:28, John Smith <[hidden email]> wrote:

Hi, I have 3 server nodes deployed on VMs as far as they are concerned it's practically bare metal installation.

My client nodes CLIENT=TRUE connect from within DC/OS Cluster using docker in either bridged network or closed DC/OS network. I.e: They are not visible to the network.

In TCP/IP Discovery this seems to work no problem, client connects and I can do cache operations no problem.

But does the server node ever attempt to connect back to the client node in any way?
And do the clients need some kind special address resolution / port forwarding?

I see there's a BasicAddressResolver class, but it's not really documented in the official docs.


javadevmtl javadevmtl
Reply | Threaded
Open this post in threaded view
|

Re: Do server nodes attempt to connect to client nodes?

Thanks! By the way in what cases, does the server need to connect back to the client? And does that in any way affect the server state and topology?

Like if a server couldn't reach a thick client for any reason would it take itself offline somehow?

On Fri, 26 Jun 2020 at 12:46, Denis Magda <[hidden email]> wrote:
John, Stephen,

Just for your reference, soon we'll introduce a configuration option that will prevent servers from initiating a connection with thick clients. The clients will be required to open the connection:

This configuration option is required for Kubernetes deployments and serverless applications and also useful for environments where servers and clients are separated with a NAT.

-
Denis


On Fri, Jun 26, 2020 at 9:35 AM John Smith <[hidden email]> wrote:
Good point. In some cases I use near cache. Maybe for the ones that don't need it, I can use the thin client.

I'm looking to see what port and I.Ps are made available to the container and see if I can set up address forwarding or whatever it's called.

On Fri, 26 Jun 2020 at 11:35, Stephen Darlington <[hidden email]> wrote:
Yes, thick client nodes are peers, and so can both accept and initiate connections to and from other nodes.

It’s often easier to get a thin-client to work under these circumstances, as they behave in a more traditional client-server manner. Is that a viable option?

Regards,
Stephen

On 26 Jun 2020, at 16:28, John Smith <[hidden email]> wrote:

Hi, I have 3 server nodes deployed on VMs as far as they are concerned it's practically bare metal installation.

My client nodes CLIENT=TRUE connect from within DC/OS Cluster using docker in either bridged network or closed DC/OS network. I.e: They are not visible to the network.

In TCP/IP Discovery this seems to work no problem, client connects and I can do cache operations no problem.

But does the server node ever attempt to connect back to the client node in any way?
And do the clients need some kind special address resolution / port forwarding?

I see there's a BasicAddressResolver class, but it's not really documented in the official docs.


dmagda dmagda
Reply | Threaded
Open this post in threaded view
|

Re: Do server nodes attempt to connect to client nodes?

If the client subscribed for data-change updates through continuous queries APIs, then any server can start opening a connection with the client to deliver an update once the time comes. There might be some other APIs that work similarly.

If the server can't reach out client it won't shut down itself.

-
Denis


On Fri, Jun 26, 2020 at 10:09 AM John Smith <[hidden email]> wrote:
Thanks! By the way in what cases, does the server need to connect back to the client? And does that in any way affect the server state and topology?

Like if a server couldn't reach a thick client for any reason would it take itself offline somehow?

On Fri, 26 Jun 2020 at 12:46, Denis Magda <[hidden email]> wrote:
John, Stephen,

Just for your reference, soon we'll introduce a configuration option that will prevent servers from initiating a connection with thick clients. The clients will be required to open the connection:

This configuration option is required for Kubernetes deployments and serverless applications and also useful for environments where servers and clients are separated with a NAT.

-
Denis


On Fri, Jun 26, 2020 at 9:35 AM John Smith <[hidden email]> wrote:
Good point. In some cases I use near cache. Maybe for the ones that don't need it, I can use the thin client.

I'm looking to see what port and I.Ps are made available to the container and see if I can set up address forwarding or whatever it's called.

On Fri, 26 Jun 2020 at 11:35, Stephen Darlington <[hidden email]> wrote:
Yes, thick client nodes are peers, and so can both accept and initiate connections to and from other nodes.

It’s often easier to get a thin-client to work under these circumstances, as they behave in a more traditional client-server manner. Is that a viable option?

Regards,
Stephen

On 26 Jun 2020, at 16:28, John Smith <[hidden email]> wrote:

Hi, I have 3 server nodes deployed on VMs as far as they are concerned it's practically bare metal installation.

My client nodes CLIENT=TRUE connect from within DC/OS Cluster using docker in either bridged network or closed DC/OS network. I.e: They are not visible to the network.

In TCP/IP Discovery this seems to work no problem, client connects and I can do cache operations no problem.

But does the server node ever attempt to connect back to the client node in any way?
And do the clients need some kind special address resolution / port forwarding?

I see there's a BasicAddressResolver class, but it's not really documented in the official docs.