I'm working on getting Microsoft Orleans "Grains" to put events onto a SignalR bus. There's an example project that does this, and I've linked to SignalR integration below.
It looks to me that this sample is using meta-data from the Azure Web and Worker roles to enumerate all the web roles, and explicitly publish messages to each one. It seems to me that if SignalR's backplane is configured properly on the azure web roles that this shouldn't be necessary -- one HubConnection/HubProxy should do it. Is that right?
In fact, when I look closely at the file linked to below, and see some of the odd logic in the Hub itself, I wonder if the sample functions as a rudimentary backplane.
I'm hoping someone with deeper SignalR experience can clarify this for me.
SignalR integration example: https://orleans.codeplex.com/SourceControl/latest#src/samples/GPSTracker/GPSTracker.GrainImplementation/PushNotifierGrain.cs
The sample is a rudimentary backplane, in that it sends the message to all web roles instances present in the deployment, and therefore doesn't require a complete backplane (such as Redis). However, it won't propgate client originated messages to the other servers.
A more complete Orleans backplane for SignalR is available here: https://github.com/OrleansContrib/OrleansR
Related
I am currently evaluating a requirement for a project for which I am considering SignalR.
Here is a brief:
We want to have a server at our end that can send instructions to a client piece sitting somewhere in the world. The client piece then is supposed to do some local processing and send back a response that the server will show to the user.
The client piece by itself should also be executable and generate the report.
So we need some .net Code(console) at the client end(across the world) and some code at the hub end(our end).
Although this is not a ASP.net application I feel like this is a good fit for websocket communication.
I am looking for some guidance on getting a very very basic structure chalked out as I am new to SignalR.
Technologies :
.net 4.5
Follow the guides for setting up your hub and using the .Net Client.
Essentially, the console applications are clients to your hub. Think of the hub as a relay. You can google "signalr console application" and get plenty of information on how to set that up.
I am new to Solace MQ. My Question is,
How I can send request to Solace MQ from asp.net web application. What are the steps I need to performe to achieve this.
I have gone through the solace MQ Dev community and developer guide but it's not too clear for me. I want to understand the basic concept to send request to Solace MQ.
There's a step by step guide, with a sample application to send/receive a message over at http://dev.solacesystems.com/get-started/dotnet-tutorials/publish-subscribe_dotnet/
To summarize it, you will need to create and IContext, followed by an ISession. Then, use the ISession to send an IMessage.
Contexts act as containers in which Sessions are created and Session-related events can be handled. Sessions create a single connection to the Solace Appliance, and can be used for publishing.
Details on the Solace API concepts can be found at
http://dev.solacesystems.com/docs/core-concepts/
I'm going to build my own system include asp.net web site and web api, they are host on separate site. Architect diagram like image link below.
Every time client update something. I need to notify to the others. For example if client 1 upload a photo via web, then client 3 and (mobile app) and client 4(desktop app) should get a notification.
My problem is how to tell SignalR send notify to clients in this case. Please advice.
Your diagram must be changed in order to achieve what you need.
In order for this to work all the client types must be SignalR aware. For the web application it's straightforward since the "client" code is the website code itself.
For the mobile and desktop you have an extra layer (webapi) which in this case is an obstacle.
You should define a SignalR hub and connect to it from all the clients: WebApp, MobileApp, DesktopApp.
Knowing this, you can make a WebAPI project containing all the API methods and the SignalR hub(s) and connect to it from the other applications, website included.
As far as I know this is the only way to make this work, as you need to include SignalR library in all the clients code and use it to communicate with the hub(s).
I'm working on a client and server application, in which client requests 'client-specific' data from the server. I'm planning on switching to ASP.NET WebAPI for server so that client can take advantage of available .NET APIs to query server for data.
This scenario works perfectly fine when the client initially connects and requests data from server, However, instead of client constantly polling for data, it should just establish a persistent connection and the server should be able to monitor the database for changes and push new data to the client that has stale data. I came across SignalR and found that it can be used with WebAPI, but can't figure out how to integrate it with database monitoring i.e. a thread or process that is constantly monitoring database for updates. Any solution? I'm open to other non-WebAPI based .NET technologies as well - basically anything .NET based that will cut-down on the development time.
ASP.NET Web API supports PushStreamContent. Take a look at the section "Push Content" in http://blogs.msdn.com/b/henrikn/archive/2012/04/23/using-cookies-with-asp-net-web-api.aspx. Here, a timer triggers content written into the stream but you can use that to poll database and write into response or build some other better mechanism
signalR could fit your requirement. You can broadcast a message to all your user or just to part of them. Your client could be a browser (with javascript) or a .net client (WPF or else).
From the server, you can call a method on the client just like that
Clients.All.MyMethodOnTheClient(param1, param2)
or
Clients.Client(connectionId).MyMethodOnTheClient(param1, param2)
The topic is too broad to answer it in 5 min. I can advise you to start here.
Then browse the server api guide, the javascript guide and the .net client guide.
Don't worry. It's quite fast to have a complete tour.
I have two different web applications that need to communicate with each others (which I can currently accomplish by using Silverlight Duplex but that doesn't scale very well). After reading about SignalR, I'd like to give this a try but failed to find much documentation on how to do this. Any advice on ho to get started would be greatly appreciated.
Thanks!
More specific Info:
Example:
Application A (Bidding Interface) - A web page to allow multiple end-users to place bids on certain items.
Application B (Managing Interface) - A web page to allow a user (or could potentially be multiple users) to monitor/control the actions from Bidding Interface.
So when a user from Application A place a bid on a piece, I'll need a way to alert Application B that a bid has been placed. Then from Application B, should the user choose to accept the bid, I need to send an alert back to Application A (to update current price, increase bid etc...)
In all honesty, in might just be simpler to have each application push the notifications to each other via standard service calls (WCF, ASMX, HTTP handler endpoints, MVC controllers, whatever). SignalR is useful in browser to server communications because there isn't a consistent way to do push from the server to a connected browser. But from web app to web app pushing is simple; Application A just calls a service endpoint on Application B to notify it of something happening.
Assuming that what you want is something like ...
User (browser) --- Application A --- Application B --- User (Browser)
Realtime communication can be done by doing the following ...
This isn't the job of signalR however something like NServiceBus would fit this very well.
you reference a bus dll file and hubs can both raise and respond to events.
In your case you would have both SignalR and your Service Bus technology work together to allow the cross application sync.
So the process is something like ...
User in application A fires up browser and requests page.
Application A creates Hub instance which internally subscribes to Service Bus events
User in application B fires up browser and requests page.
Application B creates Hub instance which internally subscribes to Service Bus events
User on either application does some action resulting in SignalR picking up a message.
SignalR raises bus event to say "This user did something" on the service bus.
Other Hub on other Application through subscribription to the event gets notified of the event and takes any action to inform its connected users of it.
Lesson to be learnt here ...
Don't try and make a technology do something beyond its purpose ... use the right tool for the job.
This entire solution can be done with little more than about 20 lines of code after getting the core framework setup.
NServiceBus can be found here:
http://particular.net/nservicebus
Disclaimer: There may be other solutions but this one suggestion don't assume this is the only way this can be solved, and the only technologies that be used in this manner.
I am not affiliated in any way with Particular or the NServiceBus product.