Let's say, I have many console apps (or windows services) that run on AWS EC2 instances,
I have a web server (IIS with MVC3 hosted) and of course I have an infinite number of web-clients...

How can I communicate between those? Let's say

I need to get every few seconds in the web browser some information
from EC2 machines - (CPU load or something like that)

On demand
(when user clicks a button on a web page) it should pull something
else (let's say AvailibleDiskSpace on C: drive) of a selected machine

What should I use - Hub or PersistentConnection? Console apps will be also clients in this case or SelfHosts (what is the SelfHost anyway?)

Is there any sample code where I can learn how to build something like that? (I believe samples on Nuget and Github and VideoTutorials show you how to build one-server/many web clients solutions but not something like I need)

You can push and pull data from the console apps to the SignalR server which can then in turn can act as a proxy to the browser clients. Of course, the SignalR server can proxy in both directions allowing any client(s) to send realtime messages or requests to any other client(s).

Your .NET and JS clients can access the same Hub or different Hubs. If all the clients access the same Hub, you might want to separate them into groups so you can distinguish between the two types of clients. If you choose to use multiple Hubs, you will likely want to make use of GlobalHost.ConnectionManager.GetHubContext<MyHub>() to communicate with clients connected to a different Hub than the one being called.

no I mean where should I put the Hub? On the MVC app, right? How then apps on EC2 machines send their stuff through web-server to the web-clients?
–
AgzamOct 3 '12 at 16:52

The EC2 machines connect to the SignalR server in you MVC app as regular clients via a .NET library called SignalR.Client. You can then let clients call a hub method on the server, which in turn broadcasts to connected clients (wheter they are JS or .NET does not matter).
–
Alexander KöplingerOct 3 '12 at 17:15

First, the console apps/windows services could just be clients the same as the browsers would be to the same Hub. There's no reason to drop down to the PersistentConnection programming model at all for this.

Second, you discuss two differenct use cases:

If you need to push the state of something every few seconds, this is perfect as a SignalR client side method. You would simply invoke the method on the clients based on whatever notification you might be receiving from the performance counters. This logic could either be within the Hub itself or could simply be from a client of the Hub calling a method that will then be "fanned" out to all the other clients of the hub (suggest the latter).

For the button press/get available space on ServerA scenario, you're talking about several layers. You somehow need to get a message from the browser to the hub to ServerA to get the result you're looking for and then respond to the browser. Honestly this isn't solved purely by SignalR. ServerA would need to have a service interface of its own that the Hub could call out to to get the result and be able to respond to the browser client. You would then have the browser call the hub method, the hub method will make a request out to ServerA, wait on the result and then return the result back to the browser. There's a lot of routing work in there to do, but nothing magical and nothing specific to SignalR. This scenario could, for all intents and purposes, be done today in a pure web service architecture.

Next, Self-Host means the hosting of the SignalR server in a host other than IIS+ASP.NET. You could, for example, spin up your SignalR service in another console app or windows service instead of hosting in IIS+ASP.NET. You can find decent documentation on self-hosting here in the SignalR Wiki.