We're developing a system that uses SignalR to push out frequent updates of some business important metrics. We'll have a medium number of connected clients, anywhere from 50 to a 1000, and each client will need a unique payload.
Based on a talk Damian Edwards gave, our load profile best matches the Specific Server scale out pattern, where we essentially assign clients to connect to a specific SignalR server in the topology, rather than use a backplane.
Rough pseudo code on how this works is that a client does a GET on our load balanced API URL, whichever server is hit responds back with its URL, and the client then configures the SignalR client library to use that URL to connect.
This looks like it will work great on-premise, but now we are planning for Azure deployments as well. Absent this requirement, Azure Web Sites are a great fit. However, this pattern requires that we can reliably identify individual instances in a Web Site, which we don't see a way to do.
Is this just breaking the abstraction that Azure Web Sites provides? Do we have to use a VM or Web Role to get a reliable, consistent IP or addressable URL for each of our SignalR instances? Or is there another way people have deployed SignalR with Specific Server to Azure.
The default Azure Websites behavior might actually work for you.
Azure Websites saves an affinity token as a cookie after the first request from a client. That affinity token ensures that all future requests from that client get routed to the same instance of the website.
If you really want to handle the load balancing yourself for some reason, that's also possible. There's an API that lets you get the affinity tokens for all your site instances.
See here for more details: http://blog.amitapple.com/post/2014/03/access-specific-instance/#.VH-KOHl0xUY