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.
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 looking to make an web application that allows to PUT ,GET etc from the client to the server. That is easy. However, if a certain event occurs on the serverside I would like to send information to the client. My clients will be mobile devices. I decided to use asp.net webapi. How should I handle sending information to the client. Should I use tcp sockets? What if the event occurs, and I need to send a json to the client, however the client has the application in suspended state. Can I buffer the messages and send it at the next socket connection?
Any insight would be greatly appreciated.
Thanks
Have you thought of trying WebSockets?. Since they are HTTP, you will not have much problems with things like firewalls. While its original intent was to be used in browsers, there seems to be libraries floating around for objective-c though I have not used any of them my self. One such library http://corner.squareup.com/2012/02/socketrocket-websockets.html
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
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've been running around in circles the past few days trying to figure out a good solution for my problem. The main key here is that this is for an iOS application. What I want is to quickly communicate from one device to another device updates. So if user 1 performs an action, I want to, in real time, tell user 2 that user 1 has performed this action.
I don't want to use Apple Push Notifications for various reasons. So that's out of the question. I looked into services like Pusher and PubNub, but those are far too expensive (and only allow a ridiculously low number of concurrent connections, ~2500). I also looked into Google App Engine's Channel API, but it works through Javascript, and would have to be implemented using shady techniques on iOS. And honestly I'd rather not use that.
So now I'm looking into XMPP in Google App Engine. It seems like it would do what I want, but I'm not sure if I'm understanding the whole picture. Couldn't I accomplish what I wanted using XMPP messages, that is when user 1 performs an action, I can notify user 2 quickly with a JSON message?
The main key here is that I would have to perform user registration for XMPP behind the scenes, using the user's unique ID. Is this possible, to automatically and without user intervention create a Jabber ID like user-unique-id#my-app-engine-domain.com?
Overall, is this a feasible solution? What am I missing? What are some exceptions?
What you have described all sounds fairly easily doable with XMPP.
Just a couple of points.
You do realize, of course, it is XML based, so your JSON messages would be embedded within XML stanzas, with appropriate escaping when necessary.
Your user registration would be determined by the server implementation, but I believe most will allow custom authentication hooks (like LDAP). So having an external registration mechanism shouldn't be a problem and is a fairly common approach.
Since you are using ios, you should be looking at XMPPFramework as your XMPP library.
Depending on your use case, you may want to look at XMPP pubsub as well for your updates, depending on how many other devices are supposed to get the message when one makes a change. I have used this approach and it works well for real time client to client updates.
AppEngine supports XMPP only as client: it can send and receive messages. The key here is if you look at the docs for sending XMPP message, that every client needs to have it's own address (JID) which is not provided by GAE.
So to support your situation, you would need to have an external XMPP server, where every client gets it's own JID and then you can send XMPP messages to them.