
Socket.IO C++ - Rauchg
http://socket.io/blog/socket-io-cpp/
======
TazeTSchnitzel
What is the point of using socket.io today? Three years ago WebSocket support
wasn't universally available, so you needed XHR etc. as a fallback. But now
it's 2015 and everything supports WebSocket. Why not just use them directly?
They have a super simple API. (see:
[http://ajf.me/websocket](http://ajf.me/websocket) \- a page I made about
them)

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.

~~~
mitchi
Socket.io is wayyyyy more noob-friendly. If you send json over the wire,
socket.io automatically converts it to a javascript object or array for you,
ready to be used. The best feature however is that you can send emit any
string as an event :

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.

~~~
greggman
> If you send json over the wire, socket.io automatically converts it to a
> javascript object or array for you, ready to be used.

That's literally 4 lines

    
    
        // sender
        ws.send({event: JSON.stringify(someObject));
    
        // receiver
        ws.on('message', function(str) {
           obj = JSON.parse(str);
        });
    

> socket.emit("hello"); and the server can listen on this event with
> socket.on("hello").

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);
        });
    
    

Sure I'm glossing over a few things but EventEmitter is 10-20 lines depending
on how crazy you want to get and wrapping both in a objects is probably
another 10-20 lines

socket.io on the other hand is a C node.js plugin and 61000 lines of JS code
:(

~~~
renekooi
Socket.IO also gives you things like cross-everything callbacks:

    
    
         // server
         io.emit('event', function (msg) { console.log('Client responded!', msg) })
    
         // client
         io.on('event', function (cb) { cb('This is my response') })
    

And it also provides socket namespacing, and "rooms" (a bit like chat rooms),
and broadcasts, and a bunch of things that I don't use.

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)

------
rburhum
We implemented our own client using libwebsockets
([https://libwebsockets.org/trac/libwebsockets](https://libwebsockets.org/trac/libwebsockets)).
Our main rationale, was that we use the 95% of the same codebase for
iOS/Android/Win/OSX/Linux.

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.

~~~
BinaryIdiot
> but the boost dependency is an immediate "oh hell no".

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"?

~~~
angersock
If you don't care about speed, Berkeley sockets (bind, listen, accept, etc.)
are just fine and very easy to deal with.

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.

~~~
BinaryIdiot
> 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?

~~~
VikingCoder
This weekend I tried to bring in boost format. I tried to bring in JUST
format, but nope... exceptions, and config, and a bunch of other stuff...
Fifteen libraries, maybe?

~~~
plorkyeran
asio specifically is available in a standalone version that does not depend on
any other boost libraries.

------
eps
One thing to keep in mind is that there are C++ devs who like Boost and there
are C++ devs who hate Boost with passion. There are also said to be devs who
are merely OK with this abomination but they are more of an urban legend
really.

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.

~~~
thwest
Devs who happily use C++ yet balk at spending a day to get a large third party
library integrated into their build are a curious bunch.

~~~
eps
It has nothing to do with the integration difficulties.

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.

~~~
thwest
That's fair. C devs are also a little more used to being tied to specific OS
facilities such kqueue/select. For me boost shines as an ASIO implementation.
When that becomes stdlib, I'm not sure I would be compelled to use it.

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.

------
rubiquity
To me adding a C++ client to Socket.IO seems like a feature to increase the
adoption of Socket.IO by embedded/IoT devices.

------
mintplant
If you're not bound to a browser, what's the benefit of using WebSockets vs.
something on top of normal sockets? Personally, I thought this was going to be
a Socket.IO _server_ in C++.

~~~
TazeTSchnitzel
The benefit is you don't need a separate service for non-web clients.

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.

~~~
hamidpalo
TCP is usable everywhere. Socket.io builds on top of websockets.

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.

~~~
TazeTSchnitzel
> TCP is usable everywhere.

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.

------
gcz92
Out of curiosity, what's the reasoning behind going with C++? Just for fun or
is there some advantage to C++ over other languages for sockets?

~~~
gabeio
I believe it's more for client side coding not node.js socket.io implemented
in c++...

~~~
gcz92
Ah, that makes sense. And I think I might have found an answer to my own
question:

"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

------
banachtarski
Why is the inclusion of boost touted like it's a good thing? Boost is fun to
play around with but for a production library, no thanks.

------
klinquist
Would love a C# implementation that I could use in Xamarin!

~~~
rational-future
Why not use SignalR?

~~~
klinquist
Right now I am using IPWorks WS client for C# and the simple 'ws' nodejs
module, they are talking to each other just fine. Doesn't have the same
capabilities as socket.io though (we have to handle reconnections a bit
differently, no concept of channels, etc). Would SignalR talk to a nodejs
socket.io server with these features?

------
donpdonp
GRPC.io - thats where the next generation of efficient multiplexed streams
will come from. Lack of a client side lib and http/2 adoption means it's still
a ways out.

~~~
TazeTSchnitzel
How does it differ from REST over HTTP/2?

~~~
donpdonp
Check out the FAQ [http://www.grpc.io/faq/](http://www.grpc.io/faq/)

------
MordodeMaru
Hope to see it soon in biicode!

------
juliangregorian
Anybody else notice that Automattic (the wordpress company) now owns the
github account for Socket.io?
([https://github.com/Automattic/socket.io/](https://github.com/Automattic/socket.io/))
As well as mongoose, kue, expect.js and others... when and why did this
happen?

~~~
aikah
Well I guess LearnBoost,whatever it was, was "acquired" by Automattic.

