The main function of SentinelSecure™ is to provide mobile application security through the use of secure containers. SentinelSecure™ allows your organization to control and manage how your people exchange relevant, time-critical information across tablets and wireless handheld devices. There are two different versions of SentinelSecure’s™ containerized solution:
SyncDog SentinelSecure™ is designed to handle the complexities of diverse, large-scale enterprise IT environments and offers several flexible deployment scenarios.
Because of the highly dynamic state of the relay messages and the speed at which they are processed, relay message queues are not persisted across multiple servers. Relay scalability is achieved primarily by device-side policy. When a user provisions, part of the user policy and configuration package that is sent to the device will include a list of relays along with a connection priority value. When a device wants to initialize a connection to the server, it will attempt to connect to the highest priority relay first, and if it gets a valid response from the server allowing to connect and initialize, it will continue to use that relay for subsequent requests. If it does not get a valid response from the relay, or if the attempted connection was disallowed because the relay responds and says it is too busy to accept new connections, the device will try to connect to the next highest priority relay, and so on. This scenario requires relays to be performance aware, and to know when they are too busy to accept new connections.
Transport servers can be configured for load balancing and failover in two ways:
Once the failover thresholds have been crossed, the transport server would send a message to the relay telling the relay to pause queuing connections for it until it gets another message that allows it to respond to messages again. SyncDog SentinelSecure™ allows for the creation of a “transport server pool” in which three transport servers could all be pulling from the same relay.
Whatever transport configuration is chosen by the system administrator, a current user and policy database must be shared between all the transport servers. Administrators would install a SQL Server cluster to which all the transport servers connect to interact with data. Data access and redundancy would be handled internally in SQL Server and would be abstracted away from SentinelSecure™ setup. All transport servers would simply connect to the cluster and retrieve their data.