Please see http://go.microsoft.com/fwlink/?LinkId=272764 for more information on using SignalR.

Mapping the Hubs connection ---------------------------SignalR Hubs will not work without a Hub route being configured. To register the default Hubs route, call RouteTable.Routes.MapHubs() in your application's Application_Start method, e.g.: using System; using System.Web; using System.Web.Routing; namespace MyWebApplication { public class Global : System.Web.HttpApplication { public void Application_Start() { // Register the default hubs route: ~/signalr RouteTable.Routes.MapHubs(); } } } Why does ~/signalr/hubs return 404 or Why do I get a JavaScript error: 'myhub is undefined'? ------------------------------------------------------------------------------------------This issue is generally due to a missing or invalid script reference to the auto -generated Hub JavaScript proxy at '~/signalr/hubs'. Please make sure that the Hub route is registered before any other routes in you r application. In ASP.NET MVC 4 you can do the following: <script src="~/signalr/hubs"></script> If you're writing an ASP.NET MVC 3 application, make sure that you are using Url .Content for your script references: <script src="@Url.Content("~/signalr/hubs")"></script> If you're writing a regular ASP.NET application use ResolveClientUrl for your sc ript references or register them via the ScriptManager using a app root relative path (starting with a '~/'): <script src='<%: ResolveClientUrl("~/signalr/hubs") %>'></script> If the above still doesn't work, you may have an issue with routing and extensio nless URLs. To fix this, ensure you have the latest patches installed for IIS and ASP.NET.

public static class UserHandler { public static HashSet<string> ConnectedIds = new HashSet<string>();

} public class MyHub : Hub { public override Task OnConnected() { UserHandler.ConnectedIds.Add(Context.ConnectionId); return base.OnConnected(); } public override Task OnDisconnected() { UserHandler.ConnectedIds.Remove(Context.ConnectionId); return base.OnDisconnected(); } } ------------------------------------------------------------------------------------------------------VIDEO ------------------------------------------------------------------------------------------------------<div> <asp:ScriptManager runat="server" ID="ScriptManager" /> <asp:Silverlight runat="server" ID="silverlightLayout" InstallationMode= "Inline" Version="1.1" Source="Page.xaml" EnableHtmlAccess="true" Windowless="true" Width="844" Height="472" P luginBackColor="Transparent" /> </div>

------------------------------------------------------------------------------------------------------website ------------------------------------------------------------------------------------------------------http://www.asp.net/signalr/overview/introduction/what-is-signalr http://signalr.net/ https://github.com/SignalR/SignalR/wiki http://msdn.microsoft.com/en-us/magazine/hh882442.aspx http://www.asp.net/signalr/overview/introduction/supported-platforms http://www.mikesdotnetting.com/Article/206/SignalR-And-Knockout-In-ASP.NET-Web-P ages-Using-WebMatrix http://www.slideshare.net/adammokan/introduction-to-signalr-10082193 ------------------------------------------------------------------------------------------------------Comparing Polling, Long-Polling (comet) and WebSockets ------------------------------------------------------------------------------------------------------With traditional polling you will make the same request repeatedly, often parsin g the response as JSON or stuffing the results into a DOM container as content. The frequency of this polling is not in any way tied to the frequency of the dat a updates. For example you could choose to poll every 3 seconds for new data, bu t maybe the data stays the same for 30 seconds at a time? In that case you are w asting HTTP requests, bandwidth, and server resources to process many totally us eless HTTP requests (the 9 repeats of the same data before anything has actually

changed). With long polling (aka comet), we significantly reduce the waste. When your requ est goes out for the updated data, the server accepts the request but doesn't re spond if there is no new changes, instead it holds the request open for 10, 20, 30, or 60 seconds or until some new data is ready and it can respond. Eventually the request will either timeout or the server will respond with an update. The idea here is that you won't be repeating the same data so often like in the 3 se cond polling above, but you still get very fast notification of new data as ther e is likely already an open request just waiting for the server to respond to. You'll notice that long polling reduced the waste considerably, but there will s till be the chance for some waste. 30-60 seconds is a common timeout period for long polling as many routers and gateways will shutdown hanging connections beyo nd that time anyway. So what if your data is actually changed every 15 minutes? Polling every 3 seconds would be horribly inefficient, but long-polling with tim eouts at 60 seconds would still have some wasted round trips to the server. Websockets is the next technology advancement that will allow a browser to open a connection with the server and keep it open for as long as it wants and delive r multiple messages or chunks of data via the same open websocket. The server ca n then send down updates exactly when new data is ready. The websocket connectio n is already established and waiting for data, so it is quick and efficient. Reality Check The problem is that Websockets is still in its infancy. Only the very latest gen eration of browsers support it, if at all. The spec hasn't been fully ratified a s of this posting, so implementations can vary from browser to browser. And of c ourse your visitors may be using browsers a few years old. So unless you can con trol what browsers your visitors are using (say corporate intranet where IT can dictate the software on the workstations) you'll need a mechanism to abstract aw ay this transport layer so that your code can use the best technique available f or that particular visitor's browser. There are other benefits to having an abstracted communications layer. For examp le what if you had 3 grid controls on your page all pull polling every 3 seconds , see the mess this would be? Now rolling your own long-polling implementation c an clean this up some, but it would be even cooler if you aggregated the updates for all 3 of these tables into one long-polling request. That will again cut do wn on waste. If you have a small project, again you could roll your own, but the re is a standard Bayeux Protocol that many server push implementations follow. T he Bayeux protocol automatically aggregates messages for delivery and then segre gates messages out by "channel" (an arbitrary path-like string you as a develope r use to direct your messages). Clients can listen on channels, and you can publ ish data on channels, the messages will get to all clients listening on the chan nel(s) you published to. The number of server side server push tool kits available is growing quite fast these days as Push technology is becoming the next big thing. There are probably 20 or more working implementations of server push out there. Do your own search for "{Your favorite platform} comet implementation" as it will continue to chan ge every few months I'm sure (and has been covered on stackoverflow before).