First I want to describe the scenario:
Let's say I have an admin page where multiple different things are displayed.
The things displayed are sent by client devices (SignalR between admin <-> clients).
Clients can see what other clients send.
They can like this stuff.
Likes have an effect to the order of items on the admin side.
Everything that is send across SignalR has to be saved in the database (can be done async) for the simple reason when somebody refreshes the site (initial page load).
Admin side
At first I wanted to do my own polling with a 5s interval (ASP.NET Web API).
But that's not real time and that's not what I call good performance (the db is queried every time).
Now my problem is to make sure that the received items via SignalR from the clients are in sync with the database.
And also the order has to match. So I have to replicate a little of the business logic concerning the likes/votes in JavaScript and on and on.
This seems prone to errors.
What are your thoughts on this?
I have made a lib that fits very good when you want to catch events fired in backend and forward them to clients. Please see my answer here
How to use a Singleton Signalr client within an MVC application
Refreshing List of news using SignalR
Related
We're planning on adding SignalR to several differnet web applications. The applications are targeted different aspects of an order. When something happens to an order, all users working with the order across all web applications should be notitfied.
Changes to an order are availible asa message on a servicebus.
We could implement the following logic in all web applications:
Subscribe to a topic (one subscription per webapp)
OnMessage -> Send orderId to hub
Hub would notify clients working on the orderId
Question is: Could we implement all this common functionality in a separate application, and all web apps would reference the same signalr scripts?
All applications live on the same domain, and it would give us a lot of benefit not having to implement signalr in every app.
Good idea, or am I missing something important here?
Edit: Put in other words: I have WebAppA, WebAppB and WebAppC all without SignalR. I'm asking if its possible to create a WebappD that talks to clients in WebApp A,B,C
Second Solution is very good. it will move signalr load (espcially memory) from your main web apps to WebAppD(signalr web app). And all your main web apps will not be dependent to signalr.
Drawbacks: You don't have any authentication on WebAppD. Because clients are authenticated on the other WebApps. You should let the WebAppD knows about orderId. That's why, you should send message to server (WebAppD) from clients(Javascript).
Because of enable cross domain settings, anyone can send message to server. Even they don't need to be connected WebAppA,WebAppB or WebAppC. Even if you solve this problem (virtual path etc), Someone is connected but not authenticated on WebAppA,WebAppB,WebAppC can sends message. Because WebAppD just get the message and it doesn't know this client is authenticated or not so it will serve this message to all others. In Short: Someone can send fake messages to other clients.
So you should share your authentication like this (or some other logic) between your web app and signalr webapp.
Other than this I couldn't see any drawback.
I am new to web development but I have a project done in VB6, it is a real time send and receive sms application. It uses a GSM modem connected to the server. My company asked me to make a web based version of my application, using ASP.NET MVC.
So I studied MVC about a month ago, created basic CRUD apps, read about SignalR but I don't want to start up a project that I am not confident if its feasible or not. So my question is, is this project possible with the said technology? (MVC, SignalR, and a GSM Modem)
If it is, can you point me somewhere I could start reading for maybe you know a similar project that can guide me through.
And if it is not, can you suggest me the appropriate tech to use for this project to be feasible? (I prefer ASP.NET MVC)
A little detail about the functionality of the project:
Has User Authentication - this user will have a simple "SMS box" type of thing which will update like a chatbox if an SMS is received in the GSM modem and this user can reply and use the GSM to send the SMS back to the sender.
IF anyone could help me, guide me, point me to some reading materials to make this project it would be greatly appreciated. Please post if you need clarifications and further explanation. Thanks!
User,
There are many ways to achieve this, so I will explain a method that worked for me a while back doing exactly this.
Based on the information provided, I will assume that you have a windows desktop app, that can already talk to the modem and perform various functions.
Trying to perform that same tasks in a web application can be a hard path to go down, what I opted for was rather simple in my opinion. You really have two separate problems, one is getting the received messages to the web application and the other getting the web application to send messages to the modem.
For handling received messages, I created a simple web api in the web application and defined a post method that is able to receive a sms object. You will need to provide the url for this call to your code that resides in your modem project, which I would convert to a windows service, if it is not already. Then when your code fires when the modem has received a sms, you simply create a object, serialize it to xml or json and then call the post method in your web api. This will give you the chance to use SignalR to notify clients or whatever else you might need to do. This is honestly is the simple part and you have the "real-time" handling ability now for receive.
For sending, there again where many options, I opted for database polling from the code inside the windows service, so when a user wants to reply or send a message, the message gets stored in a table in a database, from where the service code will pick it up and send it, once sent it will mark a field in the table as sent and possibly add a date and time as to when this happened. Again your service code could call another method on your web api, that will notify your app, that a message was sent and again you could notify the end user.
As for database polling, there are various methods, you could simply run some code every minute or some configurable value to see if there are any unsent messages.
You could use SqlDependency and handle the events in real time, you would register an event against the table where messages to be sent will be inserted into and when this happens, your service code will receive a real time event which can be handled.
You could also in the windows service, create a service, even a self hosted web api again, which can be called from your web application when it wants to send an email.
I did various implementations based on client requirements, but for me hosting either a wcf service or web api in the windows service project, proved to be the best in my opinion. You then simply have a configuration section in your web application, and provide the service address, or uri for the post method.
I hope that I have given you enough ideas to get a starting point for your project.
Currently I'm working on a ASP.NET MVC webapp which implemented a user dashboard where the user can add various charts to display data. We're using AngularJS for the client side to send the requests for data to a WebAPI solution.
The WebAPI action that returns the data is implemented as async - however, in the action we're querying some rather big Sql Server DB and apply various filters that the clients sets.
In case the user has more charts (10+) and he's "hitting" a big data set the Action on the WebAPI can take a bit of time to process.
My issue is that in Firebug I see all the GET requests being sent by AngularJS to the WebAPI, some of them (2-3) start being processed immediately, but the rest seems to get queued and in Firebug once they are finally processed I see that the Connecting time for them is huge.
Can anyone give me any idea and make understand why WebAPI doesn't seem to respond to all the requests immediately? What am I missing? Are there any settings that I could apply to improve the performance on the WebAPI?
Thank you in advance for any suggestions!
Andrei
I'm developing an application that has various types of Notifications. Examples of notifications:
Message Created
Listing Submitted
Listing Approved
I'd like to tie all of these up to SignalR so that any connected clients get updates in real-time.
As far as architecture goes - right now the application is entirely within a single solution hosted on an Azure Website. The triggers for each of these notification types live within this application.
When a trigger is hit, I'd like to tell signalR, "Hey, send this message to the following clients" along with a list of userIds. I'm assuming that it's possible to identify connected clients based on userId... and I'm assuming that the process of send message to clients should be executed outside of the web application, so as to not slow down the MVC app or risk losing data in a broken async call. First question - are these assumptions correct?
Assuming so, this means that I'll need something like a dedicated web/worker role to be sending messages to clients. I could pass messages from my web application directly to this process, but what happens if the process dies? The resiliency concerns lead me to believe that the proper way to pass messages would be via a queue of some sort. Second question - is this a valid train of thought?
Assuming so, this means that I can either use a good ol' Azure SQL database as a queue, but it seems like there are some specialized (and maybe cheaper) services to handle message queueing, such as this:
http://www.windowsazure.com/en-us/develop/net/how-to-guides/queue-service/
Third question: Should this be used as a queueing mechanism for signalR? I'm interested in using Redis for caching in the future... would Redis be better or worse than the queue service?
Final Question:
I've attempted to illustrate my proposed architecture here:
What I'm most unclear on here is how the MVC app will know when to queue, or how the SignalR processes will know when to broadcast. Should the MVC app queue blindly, without caring about connected clients? This seems to introduce a lot of wasted space on the queue, and wasted cycles in the worker roles, since a very small percentage of clients will ever be connected.
The only other approach I can think of is to somehow give the MVC app visibility into the SignalR processes to see if the client is connected... and if they are, then Enqueue. This makes me uncomfortable though because it means I have to hit that red line on the diagram for every trigger that gets hit, which - even if done async - gets me worrying about performance and reliability.
What is the recommended architecture for scalable, performant SignalR message broadcasting? Performance is top priority, followed closely by cost.
Bonus question:
What if some messages are of higher priority than others? Should two queues be used, one of which always gets checked before the other?
If you want to target some users, you'll have to come up with a mechanism, off the top of my head I can give an example, if any user hits a page, you can create a group for that page and push to all users in that group/in that page.
It's not clear to me why you need the queues. Usually users subscribe to some events when hitting a page or by some action like join a chat room, and the server pushes data using those events/functions when appropriate.
For scalability, you can run signalr in different servers, in which case you should use sql server, or service bus or redis as a backplane.
Firstly you need to create a SignalR server to which all the users can connect to. This SignalR server can be created either in the web role or worker role. If you have a huge user base then its better to create the SignalR server on a separate role.
Then wherever the trigger is hit and you want to send messages to users, you have to create a SignalR client (.NET or javascript) and then connect to SignalR server. Then you can send the message to SignalR server which in turn will broadcast to all the other users connected. After that you can disconnect the connection with SignalR server. This way you dont have to use queues to communicate with the SignalR role.
And also to send messages to specific users you can store the socket id's along with their user id's in a table (azure table storage should do) when they connect to SignalR server. Then using socket id you can send messages to specific user.
I am trying to understand how single page apps spa's work.
My understanding of a spa is that you load the data on start-up and you use ajax calls for save etc, and the whole idea is that your models cache data on the client so you have a rich snappy experience in your browser.
I am confused as to how the client stays in sync with the server changes.
E.G. If I have multiple users logged into my spa and they are all making changes, how does my client know that another user has updated a persons details if it is using cached data?
My guess is that something similar needs to happen server side to update the client on a change. Does this exist or am I misunderstanding something?
Any help or pointers to additional info would be much appreciated.
Thank you in advance.
For server to client communication you can use SignalR.
SignalR allows you to create a hub on the server which you can then tell to update the clients.
It works with a fallback mechanism, it tries to use the following techniques and falls back onto the next one if it's not available in the browser:
Web Sockets
server sent events
forever frame
long polling
Link for fallbacks: http://www.asp.net/signalr/overview/introduction/transports-and-fallbacks
Link for signalR: http://signalr.net/