ActiveSpaces TCP connectivity performance - Full peer direct‘Server’ connection versus Remote‘Client'connection.
Article ID: KB0093650
Updated On:
| Products | Versions |
|---|---|
| TIBCO ActiveSpaces | - |
| Not Applicable | - |
Description
Resolution:
You can connect to metaspace in two ways. 1). Full peer direct ‘Server’ connection. 2). Remote ‘Client' connection. Direct full peer connection : Any processes (SEEDER,LEECH,JAVA Client, BW process) can join the metaspace as a full peer directly connected to all other full peers using the (well know address) TCP discovery and listen (and metaspace name) arguments and once connected to the metaspace they can use any number of spaces, they could join some of those spaces as seeder and some of those spaces as leech. So the role of a member on a particular space (seeder or leech) is completely separate to the metaspace connection arguments (i.e. you are a member of the metaspace regardless of how you join the spaces). Full peer Members of the same metaspace are all connected to each other (full mesh / full Join) using TCP connections. The first member of the metaspace (the first node connecting to it) creates the metaspace and therefore does not make any TCP connections, but any new member of a metaspace will establish a TCP connection to all the other members of the Metaspace, therefor each member of the metaspace needs to listen to a TCP port for new members of the metaspace to be able to connect to it when they join the metaspace (effectively all full peer directly connected members of a Metaspace need to be able to establish TCP connections to each other, in any direction). The 'listen' parameter lets the user alter or specify which interface and which TCP port that particular member will try to grab in order for new metaspace members to connect to it. There also can not be any kind of ‘network address translation’ happening between any two full peer directly connected members of a Metaspace. So each new members join can take more time as the number of peers increases. Remote Client Connection Application will be able to connect into the Metaspace by making a single TCP connection to a proxy (itself a fully connected member of the metaspace). Typically, an as-agent would act as a 'proxy' for the remote member. Remote connecting applications will only ever able to be leech on the spaces they join (and never to seed). The difference between a 'fully connected TCP discovery' application being a leech on a space and a 'remotely connected' application being a leech on a space is the fact that the 'fully connected' is able to reach any seeder on that space directly (single network hop), while the remotely connected application has to do a first hop to the proxy (or proxies) it is connecting through, and then (eventually) a second network hop to the seeder (and then the response comes back to the agent and is then finally sent back to the remote client). Therefore fully connected members will always have lower latency than remote clients (on the other hand it is possible to scale the metaspace to a very large number of remote clients). At the networking level: Client
connecting to the Metaspace through a proxy only establish a single TCP
connection initiated from the client to the proxy, this means that
there is no problem in the case there is any kind of network address
translation (or unidirectional firewall rules) happening between the
client application and the proxy.
At the metaspace level: Fully connected peers are full peer members of the metaspace, this means that they have TCP connections established to each other. This is because they need to be able to communicate directly with each other for metaspace group membership protocol reasons. For example at any given point in time one of the members of the metaspace is the 'membership manager' for the metaspace and needs to send and receive heartbeat messages from ALL other members of the metaspace. Because the 'membership manager' function is fully fault-tolerant ANY member of the metaspace could potentially become the new manager (if the current manager crashes or leaves the metaspace). At the space level: Once a member is connected to a metaspace, it then joins one or more spaces, it may join some spaces as a leech and some other spaces as a seeder. This all happens at a level above the metaspace membership layer (where the TCP connections are established). If two members are leech on a space, they indeed don't need to talk to each other ... for operations on that space. But they may still need to talk to each other because one of them is a seeder on another space, or simply because one of the two may become the metaspace membership manager (and in that case they would need to send heartbeat messages to each other over those TCP connections). A remotely connected member can never become the metaspace membership manager and can never be a seeder on any space (and therefore does not need any TCP connection other than the connection is has with it's proxy as-agent). You
can have a lot more remote client applications connected to a Metaspace
than you can have directly connected full peer members. Also, if those
client applications are experiencing connectivity problems, they will
not impact the full peer members of the Metaspace. AS recommendation:
|
Issue/Introduction
ActiveSpaces TCP connectivity performance - Full peer direct‘Server’ connection versus Remote‘Client'connection.
Additional Information
ActiveSpaces TCP connectivity performance
Feedback
Yes
No
Powered by
