Lets say client x connects with Openfire 1 server and Server X is connected with Openfire 2 server. So if server X wants to send message to Client X, the communication would look like: 1. server X sends message to Openfire 2 [Client to server]
2. then openfire 2 would pass message to openfire 1 [Server to server]
3. openfire 1 sends the message to client x [server to client]
If in case all the requests start going like this, we will extra load of server to server message for all calls which could lead to scalability issue faster.
Server X --> Openfire 1 <-------
| | |
Client X <----> Load Balancer <----> Openfire 2 <---> Database
| | |
--> Openfire 3 <-------
correct me if i am wrong.
To solve this, we want to know about the openfire server upfront. So server X knows about which openfire server is connected with which client X.
Looking for inputs what are the options to resolve this.
For simplicity’s sake, let’s take the load balancer out of the picure for now. Let’s go with the most basic flow that involves two different XMPP domains (each consisting of exactly one server)
An end-user of Domain A uses a software client, Client A that is connected to any of the XMPP servers in its domain. In this example, there’s just one server in the domain: Server A. The connection between Client A and Server A is called a Client-to-Server (C2S) connection. Similarly, an end-user in Domain B, using Client B, is connected to Server B using a different C2S connection.
When the end-user that uses Client A wants to send a message to the end-user that is using Client B, the message will be composed on Client A, and delivered to Server A.
Server A wil inspect the addressing information on the message, and will determine that the message is addressed to a user on a different XMPP domain than the domain that Server A is part of. As a result, the server will use DNS to look up what servers are part of Domain B, and will establish a connection to one of those servers. In our example, there is only one server in Domain B: Server B. Server A will establish a connection to Server B (called a Server-to-Server or S2S connection), and use that connection to deliver the message that it recieved from Client A to Server B.
Server B will again inspect the addressing of the message. It will discover that the message is addressed to a client that is part of its domain. If it determins that the client is connected, it will deliver the message to Client B.
When any of the domains consists of more than one server (when clustering is being used), then there might be some cluster-internal routing when the cluster-node that receives the message isn’t the same cluster-node that has a previously-established connection to the intended recipient. This cluster-internal routing is not specific to XMPP. Openfire largely depends on the Hazelcast library for this. The clustered networks are expected to be high-availability and high-capacity networks. Apart from the largest of properitary use-cases, there is little risk in that becoming the first scalability issue that needs to be dealt with.
Does that mean if both clients (Client A and Client B) are connected to same XMPP clustered domain, DNS wont play any role?
DNS-SRV is not a replacement for load balancer. It is used if the communication between different XMPP domains happen. Correct me if I am wrong.
You mentioned that “The clustered networks are expected to be high-availability and high-capacity networks.” . Is there any official document/link for this reference?
There’s always a bit of DNS in play, I guess. Clients will need to resolve the server to which to connect to in the first place. Inter-cluster communication ideally uses multicast, so no DNS lookups should be needed there.
You can use DNS SRV records to instruct load to be distributed in a certain way, so there is a bit of overlap in functionality with a load balancer in that respect. I think you need to read up on DNS SRV, and exactly what it can do to get a clearer picture. A good place to start can be the XMPP specifications, that describe how DNS SRV records are used with XMPP.
From your questions, I’m getting the impression that you’re trying to run before you can walk. If you haven’t done so already, I’d suggest that you take some time to create a couple of small (Openfire-based) XMPP domains, connect some clients, and have them communicate with each-other. You can then experiment with various network architectures and settings. Going through that exercise will most likely help a lot to put things into perspective.