0

I have the following situation: A user logs in in a ASP.NET MVC4 app using a PC. This app is running on multiple IIS servers, behind a load balancer. After this a SignalR connection between the server and the client is established. When the user is logged on to this main app, a second screen can be added by using a tablet or phone (can be different network). Here the user also logs in and gets a SignalR connection.

In the app on the server occures a type of event and this events has to be send to both devices over SignalR. Therefore it's needed that both devices are connected to the same IIS server.

I have no experience with load balancers at all. Can I enforce that a load balancer one user, using multiple devices, always routes to the same server with all its devices? If so, which load balancer is recommended?

pexxxy
  • 489
  • 1
  • 6
  • 17

1 Answers1

0

Some load balancers can manage affinity though the use of cookies. You might be able to get away with using the same cookie values for all connections by the same logged in user. I know that a Barracuda product supports this approach. I gues others would too, you'd need to research.

An alternative would be to try and sidestep this issue and allow connections to your hub via any IIS instance and have any IIS instance be able to service the requests. If this means sharing some information between instances then you could use a shared cache (AppFabric, NCache, MemCached) as a means of achieving this. This approach would give you the benefit of better load distribution throughout your farm.

Steve Martin
  • 1,632
  • 10
  • 19
  • When I write the events I need to dispatch to the devices in a shared cache, each server has to poll the cache to see if there are some events to send to the device, not ideal. – pexxxy Jun 10 '13 at 14:55
  • Sure. It's an approach and you need to weigh up the cost/benefit. I worked on a project a couple of years ago where we had a server farm and, similarly, we used SignalR to return results to the browser where the browser may or may not have been connected to the original IIS instance after its initial request. We made a call at the time to have it poll a central 'source of truth' rather than try to force affinity. This was right for us in our circumstances and I'm not saying that it fits your picture so you ought to do some sums. – Steve Martin Jun 11 '13 at 09:51