Hosted Chat for Business
Features

architecture

Hosted and On Premise Chat Solutions

AstraChat utilizes an advanced two-tier clustering architecture consisting of a front-end application tier and a back-end data storage tier.

The front-end tier consists of “data-less” application servers that are typically virtualized Windows Servers running the AstraChat application services. The AstraChat clustering architecture enables any subscriber to connect to any application node to access their messaging services. Subscribers are not “tied” to any node or any group of nodes in the cluster. This architecture allows for virtually unlimited horizontal scale by adding application nodes as the load increases.

The back-end tier contains the data storage devices. a SQL Server cluster is used to store the subscriber database, the cluster configuration database, the chat database and the logging database.

Clustering Architecture

In this proposed clustering architecture for a hosted service three key components are used :

1 Nodes running AstraChat services.

2 Database servers running a mirrored SQL Server Cluster.

3 Load balancing switches

In this configuration the load balancers distribute incoming connections to the servers based on the traffic type and current service load. Incoming Chat connections are distributed evenly between the application nodes hosting the requested service. Fail-over from one node to another is automatic: in the event of a system failure, the load balancer removes the failed server from the group of systems that receive traffic.

Active Directory Integration

In order to allow the users to use the same credentials they have for other services when accessing the chat service, and have their passwords updated globally across all services the chat system can integrate with Active Directory.

Active Directory Alternative

Hosted AstraChat can also authenticate via your email servers or maintain its own database of user accounts

Chat Message Flow

Chat connections are routed by the load balancers to an application server which is currently part of the chat cluster. The connections are defined as ‘sticky’ so a single user will always connect to the same node for the duration of their chat session.

Messages are received from clients using secured (TLS or SSL) XMPP (jabber) protocol. If the recipient of the service is not a local user the message is relayed internally to the recipient’s server and relayed to them. If the recipient of the message is local but not online the message is stored for delivery in the SQL database. If the recipient is local and currently online the message is relayed directly to the client.