I want to create realtime notification
I dont want use node js
by the way I have ajax notification .
Its load 1s 1 time working Its right way
There are many ways to achieved real-time notification goal. One of the most famous and easy to use library for implementing more effectively notification scenario is SignalR.
According to Asp.net definition:
ASP.NET SignalR is a new library for ASP.NET developers that makes developing real-time web functionality easy. SignalR allows bi-directional communication between server and client. Servers can now push content to connected clients instantly as it becomes available. SignalR supports Web Sockets, and falls back to other compatible techniques for older browsers. SignalR includes APIs for connection management (for instance, connect and disconnect events), grouping connections, and authorization.
See:
SignalR , SignalR.net
Related
I'm looking to implement a event-based communication pattern between my microservices and I'm looking to use Azure Service Bus to handle the messaging. In the examples I've seen so far (e.g. Microsoft's eShopOnContainers) the events are handled by a common library that handles the event subscription/publishing. I'm wondering if the common library could be replaced with Azure's Event Grid service (I realise this could generate an opinion-based answer, so please remove this question if it is deemed so)?
I like how Event Grid has retry capabilities, receives events from Azure Service Bus, push-like functionality (meaning my microservice doesn't need to poll), as well as other features, so in my mind it seems like a good fit. However, I'm fairly new to the event-based communication concept so I'm well aware I could be missing something.
If Azure Event Grid could be used to handle the events, is it possible to send the event to a Web Api endpoint? Once again, the examples I've seen so far all send the event to a Azure Function trigger, but I'm not planning on using any Azure Functions for my microservices.
If anyone had any examples they could point me to where Azure Service Bus and Event Grid were used for communication between microservices, that would be appreciated.
I want to build a real-time data API using SignalR on the server. I will be building a web client that will connect with the API the "usual way".
However, I would like 3rd parties to also be able to connect to this API. These clients may be web clients or other platforms such as Windows, Mac, iOS, etc. Ideally, they'd just be able to connect via plain websockets and be totally agnostic of whether SignalR is in use on the server or not.
It seems that there are a lot of libraries out there for clients on different platforms (Swift, Objective-C, Java/Android, c++, etc) that would allow them to connect to my API. Another approach (that some of these libraries use) is to embed a hidden web view. Either way it's quite a bit to impose on the 3rd parties. It needs to be simpler.
Is there a way to write a web application (for example) that only uses standard websocket calls and talks directly to my SignalR server without needing to include any SignalR specific scripts as dependencies? Can a non-web client do the same (i.e. make standard websocket calls, with no embedded web view)?
Basically, I would like the effort 3rd parties need to go through to be no greater than if I decide to make a vanilla websocket API and avoid signalR entirely.
No. You can´t do that currently. But that will be possible in the next version of SignalR (Asp.NET Core Sockets) according to this video. The first beta release is planned for mid 2017.
UPDATE
It seams that it´s indeed possible with some workarounds. Take a look at this link.
I wonder to know which technique and tools I should use to have the ability to send real time notifications to users. Specifically if I build a messaging system.
I can see that modern social networks can send notifications about new messages almost immediately. Even when the user 'A' from one country writes a message to the user 'B' in another country you can see that the user 'A' writes a message and you immediately see it (even if those users live in different continents).
I tried to figure out how it is possible and find any information about this but without success.
The only thing I found out is the technique when we use a Redis or RabbitMQ server with several servers which acts like publishers and subscribers. Our API servers receive new messages then they push a new message in the queue then subscribers receives the messages and if they have an open WebSocket with the recipient they push this message in the WebSocket and a client receives the message.
But it really won't work if you have a distributed project and your clients are connected to the nearest servers in the nearest data center.
The question is: what technologies/techniques/anything we should use to be able to build notifications in a distributed project?
If you develop your distributed app/system using web technologies, you can consider building what is referred to as a Progressive Web App. With PWAs you can add push notifications in a relatively easy way. You could start with a PWA approach, and then decide later on if developing a native app as well (i.e. iOS or Android) would be necessary.
There are many resources to learn and guide you in developing progressive web apps. Check the references I mentioned above, and you can do this codelab as a starting point.
I want to start to create a website which is opened on a mobile phone (any kind of smartphone). This website will have the feature to control a website you have already opened on your computer. (The Volkswagen New Century Beetle from 2011 had the feature, that i could scroll via smartphone on the website opened on my desktop computer)
We have a streaming website for horsevideos, and this will be an awesome feature for our customers, if they could watch the streams on their smart tv and control via iphone/android/wp.
Also wilmaa.com from switzerland provides a remote control for smartphone to navigate on my website on smart tv/webbrowser.
Because I need a starting point to learn how it works i was checking Google, maybe there already any remote controls outside, but unfortunately i couldn't find anything.
Maybe Stack Overflow can help me by giving some starting points on how to realize this.
To do this you need some kind of 'pushing' service able to overcome the inherent drawback of HTTP that it has always been a 'pull only' system - client initiates a request, server answers. In this case you want to push an event from the server to the client.
For the past years this has been done with so called 'long polling'. This means that you 'abuse' the mechanism present in browsers that protects the server from hanging requests, but allows them to take a while. Apache is by default configured to allow a request to last 300 seconds on most platforms. Long polling works by sending an Ajax request, and if the server has no data, instead of sending that back it just waits, until either it does have data, or a long period such as a minute has expired. The client does not send a new request until it has received a response. This gives the illusion to the end user of real time feedback, and is how sites like Facebook et al have done this for years.
Since a few months it's also possible to employ a new HTML5 technology that now has stable implementations on all major browsers: Websockets. This technology allows a server to upgrade a common pull request to a full bidirectional connection, allowing realtime communication between browser and server. Regrettably, the 'regular' webservers such as Apache are not really built for this kind of logic, although it is possible to emulate it with frameworks like Ratchet. For the realtime part of the system the current platform of choice for most sites, including Stack Overflow here, is node.js - serverside asynchronous Javascript.
What I would recommend in your situation:
Set up a separate node.js server as an event dispatcher (you can get a cheap micro sized EC2 instance at Amazon for like $15 per month which will probably suffice, and is very scalable)
Keep all the other code in the regular environment where it is now, just add logic to communicate with the event dispatcher
Deploy Socket.io as your websocket handling service. It simplifies all the Javascript logic on both server and client side, and wraps a realtime connection in such a way that it's even compatible with IE5.5, by gracefully degrading towards technologies that are supported by both server and client - websockets on recent browsers, long polls or other technologies on legacy systems.
With this solution you can easily implement, with relatively little code, a system with full realtime responsiveness across multiple platforms as you described.
As for the controlling app itself, just use HTML5, with Phonegap if you intend to distribute to app stores.
I'm looking at having thousands of simultaneous connections from mobile phones to the server whereby anytime a user interacts with his cell phone, the data is sent and logged by the server. Also, anytime the server has new information for that user, the server can push that information without a browser refresh. I am wondering what is more stable and how you would build this?
A good real-time framework or infrastructure will have numerous APIs that should let you connect any device, no matter the technology, to the real-time server e.g. an iOS client library for iPhone and iPad, a JavaScript client library for numerous platforms including normal and mobile web, an Android compatible Java library and so on.
An interesting idea might be to choose which ever framework or real-time service suits your needs best and then using something like PhoneGap. But, as #rt2088 says, it depends if you need the notification app to be running as a service on the phone or as a standalone application.
The choice will also depend on whether you want to install, host, maintain and manage the scaling of your own real-time services or not. If not, there are a number of services out there who you could use so you can concentrate on building your application. If you do want to manage your own infrastructure then the Comet Maturity guide could be a good start. It's a little out of date but is still probably the best reference available.
the ability to push new content the
user based on his GPS location which
is "pinged" to our server. Based on
that, we deliver local content. What
frameworks are you talking about?
There are a number of real-time frameworks available at the moment. Some are hosted services and others require installation on your own hardware. The majority of them will come with a bunch of libraries in different technologies that make it easier to get up and running with them e.g. a JavaScript library that wraps the WebSocket object and also manages fallback for web browsers that don't support WebSockets.
I've just created a Real-Time Technologies Guide in which I've listed all the real-time technologies that I could think of and provided a bunch of tags associated with each.
wouldn't a javascript client library
cover all platforms if it is a web
appilcation?
If the application is a web application then yes, a JavaScript library would be all you need for the client application. The server side libraries that you require would depend on the real-time technology you choose.
Best solution to achieve this is to use the WebSocket communication. It is bidirectional asynchronous communication. Currently every browser supports this new standard and plenty of code snippets available. You just have to google it. There are many server and client side frameworks. choose the one best suits to your requirement.
The details of the WebSocket specification is available at -
Websocket specification
Do you need notification when user uses mobile browser of handset or the mobile handset itself (performing non-browser tasks)? Based on that, the framework to record user activity can be selected.