I'm trying to learn about WebSocket as I see many possibilities with it and would like to explore it, but I am having a hard time understanding the basic requirements for it.
There exist a ton of blogs out there praising WebSocket like was it God and they explain how to develop WebSocket applications brilliantly.
However I don't understand when they all shortly mention that you need a WebSocket compatible server and then none of them tells you how to set it up and what you need to do to make it work properly when you call it through your client side scripts etc. - Even WebSocket.org fails to explain it.
Can anyone point me in the right direction?
Say I have an ASP.NET website and would like to use WebSocket to push notifications, maybe even have a chatroom. What would I need to do to make my Javascript-based chatroom application working?
If you are using ASP.NET, you will need IIS8 to work with WebSockets integrated in the app (so you would need Windows 8 or Windows 2012). Or, you can have a WebSocket server in another port/server.
If your "push" requirements are not very exigent, you can try SignalR: http://www.asp.net/signalr. Check out their tutorials to get started. But again, you won't be able of using WebSockets unless you are using IIS8.
Other WebSocket frameworks are XSocket.NET and SuperWebSocket. Or if you want you can take a look at my WebSocketListener that I am developing, that is just a lightweight WebSocket connector and nothing more, although it is under heavy development at the moment.
From client side, the WebSocket API is the same for all browsers.
Your question is very broad and not any particular problem specific.
WS (WebSockets) is protocol that is implemented in most modern browsers and platforms, and is well consistent.
But same way as you need something to be as HTTP web server (ASP.Net + IIS, Apache + PHP, node.js, python, etc) you need similar or compatible technology for WebSockets. As it is different protocol, your technology have to support. From "recognising" traffic as WS, directing to right process via socket/proxying, handshaking, deserializing traffic into actual data, and providing you an interface to work with all of it.
So you need basically google: "%YOUR TECH/LANGUAGE% WebSockets". That will give you information on how to use WS on your platform.
You need to understand specifics that it is different protocol, so it might not be that "friendly" with some complicated infrastructure cases.
ASP.Net 4.5 do support WebSockets by default, just find documentation on how to use it in ASP.Net.
And this question would not be raised if you would try to do some experimentation and prototyping with WebSockets in first place.
Related
A friend of mine made the statement:
To share state across browsers - you need a server. You can't federate state across clients.
I get that fundamentally http is a request-response, client-server protocol, and that the browser sandbox has a security design heavily weighted around it being client-only.
I don't know the API well enough, but I found it an interesting question. I wanted to know if there was wiggle-room in this claim.
My question is: Is it impossible to implement a federated networking game in the browser without a server? (ie browsers acting as both a server and a client).
It looks like this is possible with WebRTC. The library PeerJS uses this.
It's seems to me that SignalR is only temporary step towards global domination of System.Web.WebSocket, and it's lower level System.Net.WebSocket.
If I have IIS8, and my clients have IE10, do I have any reason to use signalR?
Does it have a future?
(Of course, the same goes for Socket.IO + Node.js)
Thanks
ref:
http://pieterderycke.wordpress.com/2012/07/20/websockets-vs-signalr-or-why-you-should-not-have-to-care/
A number of advantages:
SignalR abstracts the actual connection type away so that you only deal with a logical connection. The advantage is that you can switch to other connection types if you want to without having to change your code (SSE might actually provide better performance than WebSockets in some cases).
You get the fallback options (long-polling etc.) for free in case you need to connect from a client that doesn't support WebSockets.
Hubs provide a level of organization (you can do that yourself, of course, but it's a good starting point, and it's convenient)
SignalR provides a rich API for calling a specific client, a group of clients, all clients (including the ability to exclude certain clients). Again, you can implement it yourself, so this is mostly about convenience.
You can pass strongly typed parameters between client and server (both ways).
You'll (probably) have to deal with less boilerplate code with SignalR.
Scale-out support
Off the top of my head, the group membership/broadcast and the ability to scale out on a webfarm are features that you don't get built into the WebSockets classes - so if you're using those features, you'll probably continue to use SignalR for the near future.
Additional to Damien's points:
SignalR also supports long polling and some other techniques if the user has no browser with web socket support
It's very easy to call methods on the client from the server
Also, when WebSockets is updated, SignalR will also be updated, so you won't need to worry about coding for the new version of WebSockets.
I am developing a group chat using the python Twisted framework. The technique I am using is Long polling with Ajax. I am returning SERVER_NOT_DONE_YET to keep the connection open. The code is non-blocking and allows other requests. How much scalable is it ??
However, I want to move ahead of this streaming over open connections. I want to implement a pure server push. How to do it ? Do I need to go in the direction of XMPP ? If I open a socket on the server for each unique client, which web server would best suit the bridging ? How much scalable would it be ?
I want it to be as much scalable as the C10K problem.I would like to stick to Twisted because it has a lot of protocol implementations in easy steps. Please point me in the right direction. Thanx
Long-polling works, but isn't necessarily your best option. It starts getting really nasty in terms of integration with firewalls and flaky internet connections. For example, at work, a lot of our customers' firewalls kill off any HTTP connection that isn't active for 10-20 seconds.
We've solved a lot of problems by switching over to WebSocket over SSL. WebSocket gives you a full-duplex channel, which is perfect for server push. By using SSL, firewalls are often less aggressive in their garbage collecting, and transparent proxies are often fooled by the TLS encryption. You will still need to manage the occasional disconnection on an application-level, even if you're using WebSockets instead of long-polling, but even that can be handled gracefully by having a decent recovery protocol, regardless of whatever transport protocol you use.
This being said, instead of going directly for WebSockets, we've decided to use SockJS. The main reason for this choice was that SockJS can use WebSockets when available (rfc6455, hixie-76, hybi-10), but also fall back to xhr-streaming, xdr-streaming, etc, if the client's browser does not support it (or if the connection fails). When I say that it can "fall back", I mean that the code you use on the client side remains exactly the same, SockJS takes care of the dirty work.
On the server side, the same is true. We currently use Cyclone's SockJS implementation for Twisted (in production), but we're also aware of DesertBus' implementation, which we still have to check out. There's also some other stuff that we're hoping to check out, for example WAMP, and the accompanying Autobahn|Python.
With regards to performance, we use HAProxy for SSL termination and load-balancing. HAProxy's performance is pretty amazing, on a multitude of levels.
We have migrated to WebSockets now. It works perfectly fine !!
I am searching for a good method to transfer data over internet, and I work in C++/windows environment. The data is binary, a compressed blob of an extracted image. Input and requirements are as follows:
6kB/packet # 10 packets/sec (60kBytes per second)
Reliable data transfer
I am new to network programming and so far I could figure out that one of the following methods will be suitable.
Sockets
MSMQ (MS Message Queuing)
The Client runs on a browser (Shows realtime images on browser). While server runs native C++ code. Please let me know if there are any other methods for achieving the same? Which one should I go for and why?
If the server determines the pace at which images are sent, which is what it looks like, a server push style solution would make sense. What most browsers (and even non-browsers) are settling for these days are WebSockets.
The main advantage WebSockets have over most proprietary protocols, apart from becoming a widely adopted standard, is that they run on top of HTTP and can thus permeate (most) proxies and firewalls etc.
On the server side, you could potentially integrate node.js, which allows you to easily implement WebSockets, and comes with a lot of other libraries. It's written in C++, and extensible via C++ and JavaScript, which node.js hosts a VM for. node.js's main feature is being asynchronous at every level, making that style of programming the default.
But of course there are other ways to implement WebSockets on the server side, maybe node.js is more than you need. I have implemented a C++ extension for node.js on Windows and use socket.io to do WebSockets and non-WebSocket transports for older browsers, and that has worked out fine for me.
But that was textual data. In your binary data case, socket.io wouldn't do it, so you could check out other libraries that do binary over WebSockets.
Is there any specific reason why you cannot run a server on your windows machine? 60kb/seconds, looks like some kind of an embedded device?
Based on our description, you ned to show image information, in realtime on a browser. You can possibly use HTTP. but its stateless, meaning once the information is transferred, you lose the connection. You client needs to poll the C++/Windows machine. If you are prety confident the information generated is periodic, you can use this approach. This requires a server, so only if a yes to my first question
A chat protocol. Something like a Jabber client running on your client, and a Jabber server on your C++/Windows machine. Chat protocols allow almost realtime
While it may seem to make sense, I wouldn't use MSMQ in this scenario. You may not run into a problem now, but MSMQ messages are limited in size and you may eventually hit a wall because of this.
I would use TCP for this application, TCP is built with reliability in mind and you can simply feed data through a socket. You may have to figure out a very simple protocol yourself but it should be the best choice.
Unless you are using an embedded device that understands MSMQ out of the box, your best bet to use MSMQ would be to use a proxy and you are then still forced to play with TCP and possibly HTTP.
I do home automation that includes security cameras on my personal time and I use the .net micro framework and even if it did have MSMQ capabilities I still wouldn't use it.
I recommend that you look into MJPEG (Motion JPEG) which sounds exactly like what you would like to do.
http://www.codeproject.com/Articles/371955/Motion-JPEG-Streaming-Server
Greetings. I'm planning on building a Flex based multiplayer game, and I'm researching what will be required for the server end. I have PHP experience, so I started looking at ZendAMF.
Now in this game, I'll need the concept of rooms, and real time updates to clients in those rooms, so it looks like I'll be using remote shared objects (correct, yes?). I'm not seeing where ZendAMF can support this.
So I found this page: http://arunbluebrain.wordpress.com/2009/03/04/flex-frameworks-httpcorlanorg/
It seems to indicate that ZendAMF isn't going to do what I want. WebORB for PHP seems to be the only PHP based solution that does messaging, but on that page it doesn't mention "real-time" next to it like the Java based ones below it do.
What should I be looking at for the server piece with my requirements? Do I need to make the jump to something like BlazeDS and try to pick up a bit of Java knowledge?
Thanks.
I'd highly reccommed flash media server if you have the cash.
I've had good expereince with it in the past
Both ZendAmf and weborb use http long pulling. Think of it as pinging to check for updates. If you really need TRUE realtime push notification then PHP will not be your answer due to it not having threads or long running processes. WebOrb has several servers in other languages along with BlazeDS, RubyAMF, PyAmf, and of course LCDS from adobe that allows for true messaging.
I think you already know the answer, but for other people looking into this as well:
All *AMF solutions use HTTP as transfer protocol and can't have permanent connection. AMF is sent encoded through HTTP and then it's closed.
When you want to use "real" real-time (RTMP,RTMPT), you have choices like:
opensource: Red5 (Java), BlazeDS (Java), FluorineFX (.NET)
commercial: Wowza Media Server (Java), WebORB (.NET and Java)