Socket.IO C++
socket.io
socket.io
If you're worried about firewall/proxy traversal, use wss:// (WebSocket over TLS), which not only traverses, but doesn't cause a speed and latency downgrade like falling back to XHR does.
I realise some sites might need to use socket.io if they're targeting legacy platforms, but that's an ever-shrinking slice of the market. For most sites it is probably overkill.
On top of its transport layer abstraction, socket.io adds various useful features including events, rooms, namespacing, efficient/convenient (de)serialization of both JSON and binary data, and over-the-network callbacks. I've been using it in websockets-only mode for various projects (you can limit the transports used), because I don't care for slower / less reliable transports but still want the extra features.
EDIT: If you'll allow the plug, an MMO trivia game show I made using socket.io (and three.js): http://masterofthegrid.net/
socket.emit("hello"); and the server can listen on this event with socket.on("hello"). If you want to do the same thing with the reference WebSocket you have to re-implement the same thing again and you will probably end up recoding the wrapper that socket.io already gives you.
That's literally 4 lines
// sender
ws.send({event: JSON.stringify(someObject));
// receiver
ws.on('message', function(str) {
obj = JSON.parse(str);
});
This is hardly any more lines of code
// sender
function sendEvent(eventName, data) {
ws.send(JSON.stringify({event: eventName, data: data}));
}
// receiver
ws.on('message', function(str) {
var eventInfo = JSON.parse(str);
eventEmittier.emit(eventInfo.event, eventInfo.data);
});
socket.io on the other hand is a C node.js plugin and 61000 lines of JS code :(
// server
io.emit('event', function (msg) { console.log('Client responded!', msg) })
// client
io.on('event', function (cb) { cb('This is my response') })
Sure, you can bolt all of that on in probably a few hundred lines, but socket.io also doesn't just do sockets and events :)
(And it also does it in less than 61000 lines. You still need the "ws" module to do WebSocket stuff in Node, even if you don't use socket.io)
See, for example, https://github.com/Automattic/socket.io-client/issues/572 (closed without comment).
If you want a nice websockets library that handles old browsers, use SockJS. It's far better.
[edit: fixed a silly typo]
If your language of choice has a SockJS implementation, I'd recommend it as a first option.
Also, magically trying to decode strings if they look like JSON sounds rather scary.
That's not what's going on. Each message is tagged with a "type", and one of the tags means "JSON.parse this into an object" while another means "this is just a string".
The rest of the types are for control messages (like ping/pong), I believe.
- E-commerce sites can't afford to drop customers with old browsers (what's old anyway, a browser that is a few years old should be supported regardless)
- Some corporate networks won't support anything other than plain HTTP over port 80
And so on. 'Legacy' for you is everyday business for someone else.
We don't want to be in a position where there can't be new browser engines because they're not "modern" if they don't implement literally every feature their competitors support.
Still is. IE11 is an evergreen browser with constant improvement.
> It will likely be legacy long before IE12 or whatever they decide to call it comes out.
There won't be another IE. There will be Spartan.
> They're not really going to be able to play keep up until they divorce the browser from the OS.
They basically have, long ago. IE10 and IE11 aren't Windows 8-exclusive.
Until Spartan comes out?
> There won't be another IE. There will be Spartan.
So we're going to be stuck supporting IE11 long after "Spartan" has taken hold just like every previous release? Doesn't that go against the whole purpose of the "Evergreen" browser?
> They basically have, long ago. IE10 and IE11 aren't Windows 8-exclusive.
I don't mean exclusive to the operating system. I mean that there are parts of the OS that rely on the browser libraries itself. And there are weird situations where OS things rely on IE libraries, or (Worse) Office Libraries. That at least for a while was one of the big reasons the problems would never get fixed.
FWIW, we're driving our users to deploy at least IE10 before talking to us, preferably IE11. Supporting old browsers is just not worth it--for devs in the short-term, or clients in the long-term.
Save them from themselves.
The part you missed is that it is worth it for clients in the short term. If you have an eCommerce site and a portion of your potential customers use IE8, then you cater to IE8. It's as simple as that. When your business depends on making money every month, "short term" or "long term" doesn't matter as much.
You shouldn't have any problems with firewalls so long as you use TLS. And if you don't use TLS and rely on XHR fallback, then you're suffering a downgrade in speed and latency.
Some corporate networks do MITM you and mandate HTTP only (we've seen this surprisingly often in the wild).
Now, for most apps this isn't a concern since those employees probably wouldn't be allowed to use the app, but it can be quite important for apps that specifically target large businesses.
I got curious about this library, but the boost dependency is an immediate "oh hell no". Even more so now that we have good C++11 features across the board and so the boost dependency is something we avoid like the plague (we used to have it and C++11 support was a god-sent that enabled us to get rid of boost).
Nice to see more C++ libraries here though.
So forgive me because I'm pretty new to C++ (well I knew it semi decently 12 years ago; trying to relearn now) but most of the C++ developers I know love boost especially for asio since most tcp libs seem to be very old. What is the reason it makes you go "oh hell no"?
If you do care about speed, you should be banging against the operating system's provided tools anyways (IOCP on Windows, kqueue on BSD, epoll on Linux, etc.).
If it's abstraction you care about, you shouldn't be doing networking with raw TCP anyways, and should just use zmq, nanomsg, or whatever, and not drag in the entire clown car of boost.
As far as I can tell you can just import what you want and not have to bring in the entire boost library to use asio. Is that not correct?
If this were a C++11 and standalone ASIO dependency would that change your mind? If it is a specific issue with ASIO, what sort of network transport would you want to see used for something like this (there is no network library in C++11)?
Can you expand on that?
You can also count on having 10MB+ of libraries to distribute if you use the entire boost lib (which, let's be honest, will be the case 90% of the time because people can't bother with cherrypicking features)
And just pray that you don't need to recompile boost because you're in for a fun few hours of wasted compilation because it fails at 80% because of <cryptic boost message>
If you contrast this with, say, Node.js, you could simply do "npm install boost --save-dev" and "var boost = require('boost');".
Nobody seems to use C++ package managers either, and the typical reply is to use the package manager of the operating system. But since that's not platform neutral there's a lot of wasted effort of maintaining multiple instructions to install the library. And Windows instructions typically require non-trivial amount of manual work, often even setting up weird environment variables pointing to various locations.
And then you want to build for 32bit instead of 64b and there's more manual work.
I would have imagined that this would be a solved problem by now.
> And just pray that you don't need to recompile boost because you're in for a fun few hours of wasted compilation because it fails at 80% because of <cryptic boost message>
It took my lowest spec MacBook Air about 15-20 minutes to compile from source. Does it normally take hours for you?
I wish I was a grumpy oldtimer, but I'm more of a dirty youngun'.
Note that I didn't say "don't use boost". Boost is amazing and you should use it if it saves you time. It's just that initial setup may be... let's say interesting.
Of course template-heavy, header-only libraries will increase compile time, but not insanely so. I try to be careful about including boost's ease-of-use headers which pull in everything and keep it limited to what I really need from a given sub-project.
Most of what I use from boost is in C++11, except asio, but the same principals apply.
In other words, consider the fact that by throwing Boost in the mix, you rob yourself a good half of the intended audience, if not more.
I never introduced Boost into my projects, but when one of the co-developers on an open source project where I am the lead (FlameRobin.org) said it would be useful, and explained what problems it would solve, I just said "ok". IIRC, this was circa 2007.
All those complaining about compile times should learn about PCH (pre-compiled headers). It's fairly simple and makes sure headers are compiled only once (unless they change). AFAIK, all modern compilers support PCH (GCC, MSVC, even Borland's).
Fixing a build can be pretty torturous though. My main thought when I'm looking at using a library in C++ is "oh god I hope this isn't a pain to build"
Many ++ devs, me included, come from the C background and the amount of obfuscation Boost adds to the code is simply not worth any benefits it brings along. Yes, you can do a lot with a single line of Boost'ed code, but when it maps onto pages of simpler code, you basically lose a lot of control over the code. It also bloats the binary, which again may not even register as a viable concern with some, but which does have several long-reaching complications.
This is along the lines of the traditional abstraction level debates, rather than anything particularly wrong with boost. I think it gets singled out unfairly as being a particularly difficult 3rd party library.
I should mention, people who talk without much context are a curious bunch too.
If you were adding boost to a project just to do some weird spirit/preprocessor hacks, I'd be wary. But if you told me you were going to write yet another cross platform ASIO wrapper because you couldn't figure out how to compile boost I'd be even more concerned.
If you have something TCP-based, it's usable only by non-web clients. If you have something WebSocket-based, it's usable everywhere.
Edit: An additional consideration: WebSocket is a nice, message-based protocol with easy-to-use APIs everywhere, unlike the stream-based TCP whose usual API (Berkeley sockets) is rather more difficult to use.
Socket.io is useful when you have legacy web browsers that may not do websockets. Beyond that, it does not bring much over regular websockets.
Not on the web it isn't.
I agree that socket.io offers little over WebSocket except for backwards-compatibility, but the OP's question was more about why you'd want to use WebSocket.
Maybe someone should write a TCP socket implementation for the browser instead of trying to re-implement the transport layer on top of the application layer.
"By virtue of being written in C++, this client works in several different platforms. The examples folder contains an iPhone, QT and Console example chat client!" - From the github repo
But yes, they came aboard with the LearnBoost / CloudUp acquisition nearly almost two years ago.
A lot of devs -- both pre-hire background and post-hire focus -- have little or nothing to do with the WordPress back-end.