I am in great dilemma as to use html5 websockets or signalR for a chat we are going to integrate into our asp.net mvc3 application
My dilemmas
1.Why to use signalR if it implements longpolling?
2.Isnt longpolling bad?
3.websockets and longpolling completely different?
4.Only IIS8 supports websockets?
5.Can i save the chat data into SQL database using Html5 websockets?
6.Isnt there a workaround to make websockets work on IIS7 and higher versions(i will be using chrome browser only)
Thanks for bearing with me
Why to use signalR if it implements longpolling?
Answer: to enable support for old browsers or to have a higher level of abstraction over data transfer implementation details. If you definitely will use the version of chrome that has a websockets support - use websockets (good explanation here).
Isnt longpolling bad?
Answer: actually it is not the best (see link above), but better than nothing for old browsers.
websockets and longpolling completely different?
Answer: they are quite different (again, see answer above), but there is smth in common for them (they both require a connection).
Only IIS8 supports websockets?
Answer: if you want to use pure .NET framework - yes, only IIS 8, and .NET 4.5. But you can use another websockets server (see workaround below).
Can i save the chat data into SQL database using Html5 websockets?
Answer: websockets is only a protocol to send data, so literally using it you cannot perform any action except of transferring data. However you could, say, have a token that will be send to server and will mean "save all previous data to DB". Or you could have more complex scenarios based on different kind of messages like inplemented in socket.io for node.js.
Isnt there a workaround to make websockets work on IIS7 and higher versions(i will be using chrome browser only)
Answer - yes, just do not use IIS, but another websockets server implementation (e.g. Fleck - has nice support for "old" browsers supporting webseckets) and run it alongside IIS as a separate process for example.
SignalR can support websockets if IIS and your browser support this, if not it uses longpolling.
Using SignalR will save you a lot of time reinventing the wheel, they have proven that you can create a good chat website with it.
Hope it will solve all your queries.
4. Only IIS8 supports websockets?
SignalR supports IE < 8 with Json2.js. Just get it with Nuget install-package json2
Make sure you add a reference to json2.js BEFORE signalR.js
Related
I'm about to start a project for a client that has lots of data that needs to be real-time.
There are two mobile apps that I will be building with trigger.io, as well as a web UI, and all of these need to stay in sync.
I plan to use socket.io's WebSocket implementation with my Node.js backend for the webapp & mobile apps. This will work great on iOS and modern web browsers.
However, Android's webview does not support websockets at all. And it would simply destroy the mobile app user's data plan if socket.io used its long-polling fallback on Android.
I was wondering: is there any possibility of an implementation of Java WebSockets for trigger.io Android, then exposing that to the WebView? There is a simple implementation for phonegap
I suppose I could write a trigger.io plugin for it - but I want to be sure before I jump in to this project if this is feasible / not too hard to write a plugin for.
I used trigger.io long ago, but not since all the fanciness came out like native plugins.
If using an HTTP fallback solution isn't an option (I'd do some calculations to determine if a streaming or long-polling solution would really "destroy the mobile users's data plan") then the best solution to add WebSocket support would probably be a trigger.io plugin.
At Pusher we used a Java wrapper in PhoneGap in order to get our JavaScript library to work. However we've since added HTTP fallback so I wouldn't recommend anybody use this now. The project is here:
https://github.com/pusher/pusher-phonegap-android
The problem with the Java wrapper here (we use websocket-android-phonegap) is that it doesn't support SSL connections (if I remember correctly) and it hasn't been updated for a long time.
With that in mind when we created the Pusher Java library (which supports Android) we used the WebSocket client in Java-WebSocket because it's being actively developed and supports SSL connections. I'd recommend it.
I'd be interested to hear about the support that https://github.com/mkuklis/phonegap-websocket provides.
We are currently working on an app that uses pusher.com to maintain a list of available people on our chat application.
Unfortunately, some of our users have IE < 10 (ie no websockets) and don't have flash, so pusher.com will not work. Also, pusher is becoming more and more expensive for our usage (pusher is more for few connections with lot of data going through and we're doing the opposite!)
So I'm looking for an alternative to pusher (either hosted or self-hosted) that will work on IE7+ with or without flash.
So far, here is what I'm considering:
XMPP/BOSH
socket.io (self-hosted)
pubnub
As for the scale, we will probably have to handle 100+ messages per second and 10000 concurrent users. Nobody here has ever played with socket.io (or bosh), and we do not wish to have too much maintenance work (ie deal with many servers and such). So 2 or 3 self-hosted servers is ok, 10+ isn't.
Any thoughts?
Unfortunately, some of our users have IE < 10 (ie no websockets) and don't have flash, so pusher.com will not work.
This is incorrect. Pusher (who I work for) provide fallback for older browsers. HTTP-based fallback has started to be released to go alongside the existing Flash socket fallback. So, older versions of IE were already handled with the Flash socket fallback but the HTTP-based fallback will give near 100% browser coverage.
The November 2012 issues of the Pusher newsletter has the following:
We've always loved WebSockets, and since the beginning they have been our primary transport mechanism. While they are still the best way of sending data between applications, we do sometime have to resort to various trickery to negotiate troublesome proxies. By popular demand we are soon going to be bolstering our legacy support by adding HTTP based transport to our existing fallback options.
We have already deployed some provisional endpoints which apply in a set of limited conditions, and we'll be continuing the expansion of this feature over the next few months. If you want to have early access to this as a beta user, please get in touch with support#pusher.com.
In terms of cost:
Also, pusher is becoming more and more expensive for our usage (pusher is more for few connections with lot of data going through and we're doing the opposite!)
Have you contacted Pusher support explaining your use case? Discounts may be available.
So I'm looking for an alternative to pusher (either hosted or self-hosted) that will work on IE7+ with or without flash.
There's a realtime web tech guide which has a good list of realtime web technology solutions (it's on my site and I maintain it). If you want to support IE then a solution which offers HTTP-based fallback is the safest bet.
I would personaly go with socket.io. It supports Internet Explorer 5.5+.
It supports various transports and uses the most-appropriate one to ensure browser compatibility without having special code to work with each browser. Here is the list of transports from the website:
WebSocket
Adobe® Flash® Socket
AJAX long polling
AJAX multipart streaming
Forever Iframe
JSONP Polling
You can see the full list of browser support here.
As for BOSH, here is a discussion on BOSH vs Websockets. If you go ahead with BOSH, you will be missing out on Websockets functionality that modern browsers support.
You should check out ScaleDrone as an affordable alternative to Pusher.
Well, I have doubts about this technology, more precisely in its implementation, can not find good examples on the Internet, as it involves javascript and php, only, you would have some links where I can find this stuff really works and that ?
A great source for all things Comet is Comet Daily. Unfortunately it's not updated all that often any more but there are some fantastic old articles in there. It's contributed to by guys that have been developing Comet solutions for over 10 years.
Comet seems to get incorrectly bundled as meaning just one particular connection mechanism is used, but it's actually a paradigm for realtime push from server to client. Comet servers can use HTTP Streaming, HTTP Long-Polling, classic polling and WebSockets.
If you are interested in the latest Push Technology then you should take a look at WebSockets which is a standardised approach to not only server to client push, but also bi-directional realtime communication between servers and clients (web browsers and other clients).
Some current trending push technologies are:
socket.io
Hosted WebSockets services such as Pusher - who I work for
Faye for self hosted Ruby or Node dev
SignalR for IIS and .NET
There are many more and more information on realtime web technologies can be found on this guide.
If you want to use PHP you could struggle to build an application using realtime Push which will scale above a small number of connections. Have a read through this question on concurrency - How to implement event listening in PHP for more information.
Do you specifically mean Ajax push? Because a more common method is comet push, I has been a while I worked with this, probably more browsers support this.
A good implementation can be found here:
http://www.ape-project.org/
Well it's called Ajax Push engine, so I suppose that is what you are looking for.
If you work with Java/Scala/Ruby/Groovy, take a look at Atmosphere, which is being actively developed/used (I'm the creator). There are many samples available.
Check out the Bayeux Protocol and CometD implementation in Java & Javascript.
From http://cometd.org/ :
CometD is a scalable HTTP-based event routing bus that uses a Ajax Push technology pattern known as Comet.
Here the link to an interesting article describing the technologies involved and a comparison of CometD and Atmosphere implementations.
I bet WebSockets are much faster.
So if I want to use lots of ajax continuously, WebSockets are recommended as an alternative?
It's two different technology things.
With AJAX client just send request to server and wait to response.
Websocket is HTML5 implementation for Comet technology, the idea is push information from server to client.
Ajax is slower because the overhead.
But Ajax is more compatible, Websocket is currently a bit experimental and it is not widely supported by most browser.
I think is not a issue of speed, is a issue of comunication and real time process
If you're in regular need of asynchronous data transmission I'd say you should try out websockets, it's really easy to use. One problem is - because of the early stage - the websocket interface might change (which has happended already) and render your web application unusable until you update your code.
Definitely WebSockets!. During my last internship, we used WebSockets together with Erlang to build a chat app for feature phones. Not only was it resource-efficient, it was also faster,
and really realtime - connections are always open, until either end closes.
And oh, they are experimental but works well on Chrome, Firefox, Android and iOS.
The only problem was with parsing data with BB which was because of the library we were using, so we rewrote the library's data parsing algorithm and it worked.
We tested on only these platforms.
You can checkout Socket.IO which improves upon the raw implementation of WebSockets.
Visit this link for some quick demos: http://socket.io/#how-to-use
Of course I am aware of Ajax, but the problem with Ajax is that the browser should poll the server frequently to find whether there is new data. This increases server load.
Is there any better method (even using Ajax) other than polling the server frequently?
Yes, what you're looking for is COMET http://en.wikipedia.org/wiki/Comet_(programming). Other good Google terms to search for are AJAX-push and reverse-ajax.
Yes, it's called Reverse Ajax or Comet. Comet is basically an umbrella term for different ways of opening long-lived HTTP requests in order to push data in real-time to a web browser. I'd recommend StreamHub Push Server, they have some cool demos and it's much easier to get started with than any of the other servers. Check out the Getting Started with Comet and StreamHub Tutorial for a quick intro. You can use the Community Edition which is available to download for free but is limited to 20 concurrent users. The commercial version is well worth it for the support alone plus you get SSL and Desktop .NET & Java client adapters. Help is available via the Google Group, there's a good bunch of tutorials on the net and there's a GWT Comet adapter too.
Nowadays you should use WebSockets.
This is 2011 standard that allows to initiate connections with HTTP and then upgrade them to two-directional client-server message-based communication.
You can easily initiate the connection from javascript:
var ws = new WebSocket("ws://your.domain.com/somePathIfYouNeed?args=any");
ws.onmessage = function (evt)
{
var message = evt.data;
//decode message (with JSON or something) and do the needed
};
The sever-side handling depend on your tenchnology stack.
Look into Comet (a spoof on the fact that Ajax is a cleaning agent and so is Comet) which is basically "reverse Ajax." Be aware that this requires a long-lived server connection for each user to receive notifications so be aware of the performance implications when writing your app.
http://en.wikipedia.org/wiki/Comet_(programming)
Comet is definitely what you want. Depending on your language/framework requirements, there are different server libraries available. For example, WebSync is an IIS-integrated comet server for ASP.NET/C#/IIS developers, and there are a bunch of other standalone servers as well if you need tighter integration with other languages.
I would strongly suggest to invest some time on Comet, but I dont know an actual implementation or library you could use.
For an sort of "callcenter control panel" of a web app that involved updating agent and call-queue status for a live Callcenter we developed an in-house solution that works, but is far away from a library you could use.
What we did was to implement a small service on the server that talks to the phone-system, waits for new events and maintains a photograph of the situation. This service provides a small webserver.
Our web-clients connects over HTTP to this webserver and ask for the last photo (coded in XML), displays it and then goes again, asking for the new photo. The webserver at this point can:
Return the new photo, if there is one
Block the client for some seconds (30 in our setup) waiting for some event to ocurr and change the photograph. If no event was generated at that point, it returns the same photo, only to allow the connection to stay alive and not timeout the client.
This way, when clients polls, it get a response in 0 to 30 seconds max. If a new event was already generated it gets it immediately), otherwise it blocks until new event is generated.
It's basically polling, but it somewhat smart polling to not overheat the webserver. If Comet is not your answer, I'm sure this could be implemented using the same idea but using more extensively AJAX or coding in JSON for better results. This was designed pre-AJAX era, so there are lots of room for improvement.
If someone can provide a actual lightweight implementation of this, great!
An interesting alternative to Comet is to use sockets in Flash.
Yet another, standard, way is SSE (Server-Sent Events, also known as EventSource, after the JavaScript object).
Comet was actually coined by Alex Russell from Dojo Toolkit ( http://www.dojotoolkit.org ). Here is a link to more infomration http://cometdproject.dojotoolkit.org/
There are other methods. Not sure if they are "better" in your situation. You could have a Java applet that connects to the server on page load and waits for stuff to be sent by the server. It would be a quite a bit slower on start-up, but would allow the browser to receive data from the server on an infrequent basis, without polling.
You can use a Flash/Flex application on the client with BlazeDS or LiveCycle on the server side. Data can be pushed to the client using an RTMP connection. Be aware that RTMP uses a non standard port. But you can easily fall back to polling if the port is blocked.
It's possible to achive what you're aiming at through the use of persistent http connections.
Check out the Comet article over at wikipedia, that's a good place to start.
You're not providing much info but if you're looking at building some kind of event-driven site (a'la digg spy) or something along the lines of that you'll probably be looking at implementing a hidden IFRAME that connects to a url where the connection never closes and then you'll push script-tags from the server to the client in order to perform the updates.
Might be worth checking out Meteor Server which is a web server designed for COMET. Nice demo and it also is used by twitterfall.
Once a connection is opened to the server it can be kept open and the server can Push content a long while ago I did with using multipart/x-mixed-replace but this didn't work in IE.
I think you can do clever stuff with polling that makes it work more like push by not sending content unchanged headers but leaving the connection open but I've never done this.
You could try out our Comet Component - though it's extremely experimental...!
please check this library https://github.com/SignalR/SignalR to know how to push data to clients dynamically as it becomes available
You can also look into Java Pushlets if you are using jsp pages.
Might want to look at ReverseHTTP also.