2. What I’ll be talking about
● Scaling out your SignalR application
● Securing your endpoints
● Cross domain calls
● Things to watch out for
● Alternatives to SignalR
3. Scaling out your SignlaR app
● Why is it important?
○ Cloud deployments usually require more than 2
instances
○ You will need to scale out some day, so better know
your options
● Challenges
○ SignlaR needs to be aware of all connections, it
needs some way of sharing data between multiple
servers
○ All servers in the pool need to be notified when client
sends a message, connects or disconnects
○ Message patterns may vary quite a lot between
applications
4. Built-in scale-out support
● SignalR backplane
○ Azure ServiceBus
■ No setup needed
■ Reliability provided by ServiceBus
○ SQL Server
■ Database needs to be created upfront
■ Familiar to most developers
○ Redis
■ Install your own or use one of the "as a service"
options
■ Fast - in-memory store
○ NServiceBus
■ 3rd party alternative to Azure ServiceBus
5. DIY Scale-out
○ One "beefy" server
■ you can tweak it for great performance
■ you need to think about failover
strategy
■ need to be aware of the scale-up
ceiling
○ Context specific
■ great performance
■ can distribute the load more evenly
■ distribution strategy needs to be
thought through
6. When to use which?
● For most cases - start with built-in backplane
of choice
● If you're expecting high volumes of
messages eg. realtime gaming consider DIY
approach
● See this great talk on the subject:
○ "Scaling the Real-time Web with ASP.NET SignalR"
http://channel9.msdn.com/Events/Build/2013/3-502
8. Securing your endpoints
● SignalR doesn't provide any authentication
features
● Use your existing authentication eg. Forms
● Use Authorize attribute to control access to
the hub or hub methods
● Do not display connectionId to the clients as
it is used in identity verification mechanism
9. Securing your endpoints
● Never blindly trust the client as it can be
hijacked or spoofed
● Don't assume client is always the browser
● Communication over ws:// is unencrypted -
use wss:// instead!
● validate origin of your clients
● encode input that you broadcast to other
clients
10. Cross domain calls
● on the client SignalR automatically detects
cross domain URL
● it will use XHR by default with fallback to
jsonp
● on the server you need to explicitly allow
cross domain connections
RouteTable.Routes.MapHubs(
new HubConfiguration(){ EnableCrossDomain = true });
11. Things to watch out for
● You need one of the supported OS-es
(>Windows Server 2008R2 or > Windows 7)
● You need .NET Framework > 4.0
● IIS7 or 7.5 needs URL Extensions module,
IIS8 has builtin support
● On the client you need jQuery 1.6.4+
● For websockets transport you need the
latest browser
● Complicated stack
● DPI
● Don’t put blocking calls in your hub methods
12. SignalR alternatives
● Socket.IO + NodeJS
○ You can run it on Azure (yes it does run NodeJS :)
○ It's mature and widely used
○ It's not as integrated into .NET environment as
SignalR
● SuperWebSocket
○ Multiple hosting options (windows service, console
app, web app)
○ Supported on Mono
○ Lower level
● Since .NET 4.5 WCF supports Websockets
as transport
