I am building a social application and was wondering how facebook achieve their notifications.
As you know, facebooks notifications are instant. As soon as someone takes an action, people are notified.
I assume they don't have a query running on the database all the time.
Can someone point me in the right direction. Thanks
Since your question is tagged with C#, ASP.NET you should use the awesome SignalR library. Basically SignalR enables you to send push notifications to the clients. Which exact underlying technique it uses is influenced by the capabilities of the Server and the Client.
There is a big real time chat site called jabbR that is built on top of SignalR:
http://jabbr.net/
Here are some more links that should get you started.
Project site: http://signalr.net/
Hosted Code (Open Source): https://github.com/SignalR/SignalR
Wiki: https://github.com/SignalR/SignalR/wiki
Projects using it: https://github.com/SignalR/SignalR/wiki/Projects-Using-SignalR
Facebook uses a messaging protocol (which it designed) called Thrift. This allows notifications from clients to servers with very low latency. I would imagine updates on the server would be triggered depending on the user action and relevant users that are logged in would be notified by the same mechanism.
Using a messaging protocol such as thrift (also see Protocol buffers) clients don't have to poll the server for updates, instead the server can push notifications to clients. To do this the server needs to have a notion of who is logged in at any one time (Login, logout handshaking) and of them, who should receive notifications from a particular client action.
Easier said than done, especially when you have 800 million potential users logged in!
You might want to take a look at http://nodejs.org/ - it is an event-driven model which is perfectly ideal for a 'social network' / instant notifications scenario.
FYI: You also might find that using a non-SQL database such as MongoDB (http://www.mongodb.org/) will be a lot faster when querying from the DB since each 'person' object in a social network scenario has his/her own unique attributes - which in a normal SQL database is hard to design.
Related
Developing a messaging application for web and mobile with real-time notification. Project flow is ..
Backend - DataBaseOperations and Services
Web
APi (for mobile app)
I need to send messages from the server to a user that can be connected from more than one location (web and mobile app).
Web and API works separately and access Backend. Please share suggestions what flow should I use to implement singalR in my project
This is a broad question, but I'll give enough to get you started in the right direction. Since you're going to be in load-balanced environment, you'll need to implement a backplane. This sits behind your web servers and aggregates the messaging. Here are some links that will guide you set up SignalR:
https://www.asp.net/signalr/overview/guide-to-the-api
https://www.asp.net/signalr/overview/guide-to-the-api/hubs-api-guide-javascript-client
https://www.asp.net/signalr/overview/performance/scaleout-in-signalr
Also, you'll need these nuget packages (minimum):
Microsoft.AspNet.SignalR.Redis or SqlServer
Microsoft.AspNet.SignalR
Microsoft.Owin
There is nothing really special in what you want to achieve.
Your client app needs to be authenticated before sending SignalR messages. That way you can identify a user and protect your server resources.
That´s the first part I would start looking into (there are tons of info about this matter if you google it).
Then you need to send a message from the server to a user and that user can have 2 client apps connected (web and mobile or even more, like other browser tabs). That can be achieved using SignalR groups.
A SignalR group is just a group of connections (not users) with a given name.
One common scenario is creating a group for each user, and that group will hold the connections of the user. This is a logical pseudo structure of how SignalR groups work (not actual code):
Group name: "johnUser"
Group connections: [
00001, // mobile app connection
00002, // brower tab connection
00003, // broswer tab connection 2
0000n // etc
]
Those numbers are simulations of Connection ids. SignalR creates them for you.
Then you just need to send a message to the group, and all connected clients will get it.
If you are just starting with SignalR I would not complicate things implenting a backpane unless you really need it and you know what you are doing. A single server can handle hundreds of concurrent connections and you can scale-out later if you want.
Regarding architecture, it´s not very clear what you mean by Web and API works separately. It´s better if you ask more specific questions after you actually try to code something.
We are building an application which is suppose to connect to the Support Engineer's Mobile phone and will alert him about any job to be done.
This application will be based on 2 parts. one is Control Centre part where the interface will be built using Silverlight 4.0 and ppl from Control Centre will be using it using normal pc over internet. The 2nd part is based on the Mobile Part where the support Engineer will be sent a communication via some magic that there is a job. And if the support Engineer will accept the job then the job will assigned to his tasks list...
Now the only issue is that how we communicate to the support Engineer on his mobile. We have couple of options...like SMS, Email over SMS etc...
SMS option is costly, so due to the cost management has refused the option, but actually SMS is fine as far as it is sent from the control Centre, but how we get the reply back from the support engineer. Coz we dont want the support engineer send us reply VIA sms coz this will cost him(thats why management refused this option). We have decided a solution that built a custom application for windows mobile which will intercept the coming SMS on the Support Engineer's mobile and will rasie a poupup detailing the job specs and on the same popup there will be couple of buttons like Accept, Reject. what ever the action will be taken it will update the control room via internet/WCF/HTTP. I have no idea how? and thats why I am here.
I am posting all this LOVE STORY so that any body senior can guide me abut the architect if it is ok or not...or any other options we can dig down further.
I appreciate your participation in this regard.
Thanks
Communication to the device is typically the hard part because the device rarely will have a routable network address. Sending an SMS is a reasonable way - so is sending an email (that's how the Microsoft email transport for WCF works). Another option is to have the device periodically "check in" to a server to see if it has any messages waiting.
Communication back is pretty simple. Build up a public web/WCF service that the devices communicate back to. Personally I'd probably lean toward a REST service to keep your mobile connection point a bit more open in the event you want to connect via something that maybe doesn't support WCF.
#Shax I've not done any mobile development but I think you need a WP7 app that will poll control center server over HTTP etc. if there is any job for the engineer. Another option will be to push any job notification from server to mobile. But I am not sure if this (push notification) is easier and/or cost effective.
Another option will be of setting up a website with details of jobs, then you can alert engineer with an SMS. Upon receiving SMS engineer can log into website and get details of the job.
I am looking to build an online customer support system for one of our company sites and had a few queries with regards to the structuring.
The scenario is this. We would like users of our site to be able to click a "Live Chat Support" button, at which point they would get a popup that tries to connect them to one of our support team.
Our support team on the other hand, will be running desktop clients. Whenever a user on our site clicks the link, all of the desktop clients will "ring". Whenever a support team member "answers" the call, the other clients will stop ringing and that member will begin chatting with the web user.
Given that our desktop client will be made using WPF in C#.NET and our site is ASP.NET MVC 2 - what would be the best way to establish communication between the two?
My initial thoughts were to have the web side store the chat in an SQL database and somehow "Ping" the relevent desktop client telling it to update its chat log. Similarly for the desktop to the web. But I am unsure how to go about implement this between two different platforms. If it were desktop client to desktop client I imagine it would much easier, but this is not the case.
Also, please bare in mind that I realise there are already commercial applications out there that do this. However, we require some bespoke functionality that goes beyond a simple chat - it is not worth going into the specifics but basically we must implement our own solution.
Any help is much appreciated.
Web technology is an inappropriate platform for implementing real-time interaction. It can be done, of course, but you will certainly have issues with scalability, responsiveness and development effort. I urge you to examine your requirements very carefully and consider whether it is at all possible to leverage a vendor product to accomplish what you want to do.
If you still want to strike out on your own, the main hurdle you will have to overcome is how to push messages to the browser. "Pinging" the browser from the server is impossible using pure web technologies, because HTTP is built on a "pull-only" request/response model. There is no persistent connection maintained between the client in the server. After the server has finished sending the page to the broswer, the connection is gone.
You could poll the web server for new messages, but this is not a scalable solution. If you're only dealing with a very small (say single digits) number of users, then this might work, but your responsiveness will be limited by the speed at which you poll, and the faster you poll, the less scalable this solution will be.
A better solution would be to use Silverlight, Flash, or some other thick-client technology running in the browser. Then you could implement a service that handles message routing between clients. This article on CodeProject might be a good place to start.
I hope someone can guide me as I'm stuck... I need to write an emergency broadcast system that notifies workstations of an emergency and pops up a little message at the bottom of the user's screen. This seems simple enough but there are about 4000 workstations over multiple subnets. The system needs to be almost realtime, lightweight and easy to deploy as a windows service.
The problem started when I discovered that the routers do not forward UDP broadcast packets x.x.x.255. Later I made a simple test hook in VB6 to catch net send messages but even those didn't pass the routers. I also wrote a simple packet sniffer to filter packets only to find that the network packets never reached the intended destination.
Then I took a look and explored using MSMQ over HTTP, but this required IIS to be installed on the target workstation. Since there are so many workstations it would be a major security concern.
Right now I've finished a web service with asynchronous callback that sends an event to subscribers. It works perfectly on a small scale but once there are more than 15 subscribers performance degrades considerably. Polling a server isn't really an option because of the load it will generate on the server (plus I've tried it too)
I need your help to guide me as to what technology to use. has anyone used the comet way with so many clients or should I look at WCF?
I'm using Visual C# 2005. Please help me out of this predicament.
Thanks
Consider using WCF callbacks mechanism and events. There is good introduction by Juval Lowy.
Another pattern is to implement blocking web-service calls. This is how GMail chat works, for example. However, you will have to deal with sessions and timeouts here. It works when clients are behind NATs and Firewalls and not reachable directly. But it may be too complicated for simple alert within intranet.
This is exactly what Multicast was designed for.
A normal network broadcast (by definition) stays on the local subnet, and will not be forwarded through routers.
Multicast transmissions on the other hand can have various scopes, ranging from subnet local, through site local, even to global. All you need is for the various routers connecting your subnets together to be multicast aware.
This problem i think is best solved with socket.
Open a connection to the server, and keep it open.
Could you have a slave server in each subnet that was responsible for distributing the messages to all the clients in the subnet?
Then you could have just the slaves attached to the central server where the messages are initiated.
I think some of you are vastly overthinking this. There is already a service built into every version of Windows that provides this exact functionality! It is called the Messenger service. All you have to do is ensure that this service is enabled and running on all clients.
(Although you didn't specify in the question, I'm assuming from your choices of technology that the client population of this network is all Windows).
You can send messages using this facility from the command line using something like this:
NET SEND computername "This is a test message"
The NET SEND command also has options to send by Windows domain, or to specific users by name regardless of where they are logged in, or to every system that is connected to a particular Windows server. Those options should let you easily avoid the subnet issue, particularly if you use domain-based security on your network. (You may need the "Alerter" service enabled on certain servers if you are sending messages through the server and not directly to the clients).
The programmatic version of this is an API called NetMessageBufferSend() which is pretty straightforward. A quick scan of P/Invoke.net finds a page for this API that supplies not only the definitions you need to call out to the API, but also a C# sample program!
You shouldn't need to write any client-side code at all. Probably the most involved thing will be figuring out the best set of calls to this API that will get complete coverage of the network in your configuration.
ETA: I just noticed that the Messenger service and this API are completely gone in Windows Vista. Very odd of Microsoft to completely remove functionality like this. It appears that this vendor has a compatible replacement for Vista.
I have an application, where I need to add role-based messaging. The messages are generated ny the application itself, and every message have an starttime (where is show on the client message-window) and an expire-time. Depending on your role, you will see a subset of the messages. Some messages are VERY important, and should be pushed to the client instantly (we are talking milli-seconds - not seconds). Also - when a user log in, he/she should be the current messages for his/her role.
Basically this is a blackboard, where the client see a view of the blackboard (depending on the role). It has to be really fast and reliable, as it will be used in an emergency centre handling calls for ambulances and fire)
Anyone know which technology I should use (application is written in .NET 2.0) or if a product exists, which I could use?
You may try using Retlang.
Sounds to me like this is a dream, role for Tibco RV / multicast, if your org has the dough for the license/backend...
If not, have a look at UDP multicast where you server would broadcast all blackboard events, and each client would filter what needs to be displayed.
Cheers,
Florian
You may try GigaSpaces http://www.gigaspaces.com they provide a pretty mature platform (you may say enterprise ready) for blackboard/messaging systems featuring support of Java and .NET and ability to deal with blackboards/queues/roles on a very fine grade granularity.