Perhaps you’ve setup a Rallypoint and have lots of users connecting to it. But you're running out of CPU because you have thousands of users talking away like crazy. Or, you have have groups of people in different parts of the world that need to connect to their own Rallypoints—but they all still want to communicate with each other. Or, you have a need to provide additional Rallypoints for failover and redundancy purposes. Or, something else...

The solution here, generally speaking, is to just add more Rallypoints. But, you want all those Rallypoints to interconnect with each other. That's where Rallypoint meshing comes in.

For this example we're going to assume we want to setup a bunch of Rallypoints in a cloud environment such as Amazon Web Services (AWS). We'd like to make those Rallypoints available to our users spread around the world. And we don't want to have those users connect to particular Rallypoints. Rather, we want any user to connect to any available Rallypoint and have the Rallypoints take care of forwarding traffic amongst themselves to create what looks like a big, centralized, cloud-based Rallypoint to our users.

First, we're going to need something that front-ends all these Rallypoints; offering a single DNS name (or single IP address) that all our users connect to. Let's call it cloudrp.example.com. Also, for purposes of this discussion, we'll say we're going to do all this in Amazon Web Services, taking advantage of Amazon's Elastic Load Balancer.

In an ideal situation, we'd use Rallypoints' ability to forward traffic to a multicast backbone to create something like below:

But, sadly, our cloud provider does not support IP multicast (and that is, in fact, true of AWS as well as most of cloud providers). Also, multicast networks can be difficult to setup and maintain so sometimes its just easier to go with unicast.

So, we'd still like to have the logical setup we described above but we have to figure a way to use something other than a multicast backbone. The answer is to create a Rallypoint Mesh.

A mesh is simply a configuration where Rallypoints connect directly to each other for purposes of traffic forwarding. This is not too much different from the way in which IP multicast works anyway. In this case, it's just that the Rallypoints themselves are doing 'multicasting" rather than utilizing the IP network for that purpose.

As you can see below, what we've done is to have each Rallypoint in our cloud connect to every other Rallypoint. Now, when a client connects (indirectly) to a Rallypoint, it's traffic is forwarded to other Rallypoints - just like multicast. It's actually rather straightforward.

You might be wondering if all traffic from all Rallypoints is forwarded to all other Rallypoints. Doing so would be inefficient, so what Rallypoints do instead is to "subscribe" to each other's individual streams. Thus, if client 1 connected to RP1 and client 3 connected to RP3 and both are registered/subscribed for the same stream, that stream's traffic only flows between RP1 and RP3 - bypassing RP2. And what about security on these links between Ralypoints? Well, they're TLS connections just like from clients to Rallypoints and are subject to the same level of X.509 mutual authentication and TLS encryption.

Lastly, while latency does increase when a mesh of Rallypoints is being used, it increases only by a minuscule amount. Remember that Rallypoints are just packets routers; they do not process traffic payloads, and therefore introduce only milliseconds worth of latency.