8 ms·
Socket.IO C++
- gcz92 12y agoOut 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 12y agoI believe it's more for client side coding not node.js socket.io implemented in c++...
- gcz92 12y agoAh, 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
- rburhum 12y agoWe 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.
- snissn 12y ago> the boost dependency is an immediate "oh hell no" Can you expand on that?
- pikzen 12y agoBoost makes you enter header and linking hell. I'm talking "an entire day to figure out how to include that in your makefile and why the fuck doesn't it link correctly" level hell. 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>
- mitchi 12y agoThis... Boost will ruin your compile times. I'm addicted to instant compilation so I avoid template hell.
- neomantra 12y agoThey were referring to compile times to build boost itself, not of their own projects. On most Linux distros, there are binaries already available so that's not a problem; yes with brew on OSX it takes a long time but you don't do it that often. 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.
- BinaryIdiot 12y agoHmm, granted I'm very new to boost and to C++ in general because I'm relearning it but a couple of nights ago I grabbed boost, compiled from source and tried out an asio example and it all seemed to work pretty easily. Maybe I need to get into more complex projects to see how bad it gets (which is worry-some since I'm essentially a newbie and don't want to waste my time learning something that won't be useful later (or just painful)). > 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?
- BinaryIdiot 12y ago> 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"?
- taf2 12y ago10 years ago for me it was because it was really hard to get it to compile. I might get it setup on my cygwin install or my linux but have trouble compiling it on both. I was able to get mozilla compiling faster/easier then boost... It's probably improved a lot since then, but back then if you had asked me to use boost I'd be rather upset as well... I think now days at least on linux there are packages for boost so it's not bad at all and also homebrew for mac so that's exciting.
- mlvljr 12y agoIIRC was no prob with MinGW 7-8 years ago, btw (and no Cygwin weirdness) :)
- angersock 12y agoIf 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 12y ago> 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?
- deleted 12y ago[deleted]
- zaphoyd 12y ago`but the boost dependency is an immediate "oh hell no"` 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)?
- rburhum 12y agoYes, it would change my mind if all the dependencies are easy to compile and work cross-platform (Android/iOS/OSX/Linux/Windows) without a problem.
- TazeTSchnitzel 12y agoWhat 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.
- Xeoncross 12y agoCountries still block websockets from other countries. We don't use pure websockets because AJAX polling still works even when firewalls and other hardware stop websockets.
- TazeTSchnitzel 12y agoEven over TLS? Are your connections being MITMed? 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.
- bryanlarsen 12y agoWe tried switching from SockJS to pure websockets and had to revert because it broke too many users, even though our website only supports WebGL (IE11, etc) and all communication is done over https/wss. One of the biggest problems was plugins like the zenmate privacy plugin https://chrome.google.com/webstore/detail/zenmate-security-privacy/fdcgdnkidjaadafnichfpabhfomcebme?hl=en https://chrome.google.com/webstore/detail/zenmate-security-p...
- deleted 12y ago[deleted]
- klinquist 12y agoWould love a C# implementation that I could use in Xamarin!
- rational-future 12y agoWhy not use SignalR?
- klinquist 12y agoRight 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?
- mintplant 12y agoIf 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 12y agoThe 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 12y agoTCP 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 12y ago> 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.
- rpcope1 12y agoI had the same gut feeling. TCP already seems like a fine enough abstraction (especially in comparison to UDP), and it is actually literally _everywhere_. 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.
- alexchamberlain 12y agoBecause firewalls are really stupid, and can be fouled into believing your app is a web browser (which I guess it kind of is at that point).
- rubiquity 12y agoTo me adding a C++ client to Socket.IO seems like a feature to increase the adoption of Socket.IO by embedded/IoT devices.
- donpdonp 12y agoGRPC.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 12y agoHow does it differ from REST over HTTP/2?
- donpdonp 12y agoCheck out the FAQ http://www.grpc.io/faq/ http://www.grpc.io/faq/
- deleted 12y ago[deleted]
- vidarh 12y agoThat's a bold claim. RPC mechanisms is one of those spaces - like IRC clients, text editors and parser generators - that there seems to be more implementations of than there are extant users.
- eps 12y agoOne 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.
- babuskov 12y agoI guess I belong to the "urban legend" category then. 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).
- thwest 12y agoDevs 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.
- overgard 12y agoC++ devs are a curious bunch :-) 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"
- banachtarski 12y agoWhy do you think it's only "a day." Also, you are forever introducing a dependency in your build chain, codebase, and executable. EVERY 3rd party dependency should be audited as such (performance, security, usability, etc). Boost is no exception, but for the amount of things it comes with (often), and the strain on the compiler requirements it produces, it is typically included as a last resort. I should mention, people who talk without much context are a curious bunch too.
- juliangregorian 12y agoAnybody 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 12y agoWell I guess LearnBoost,whatever it was, was "acquired" by Automattic.
- deleted 12y ago[deleted]
- deleted 12y ago[deleted]
- mmanfrin 12y agoLearnBoost/Guillermo made Socket.io; they had a startup under the same umbrella called CloudUp; Automattic acquired CloudUp/LearnBoost/Socket.io (2 years ago I think).
- georgestephanis 12y agoWe do a lot more than just WordPress. :) 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. http://automattic.com/work-with-us/ http://automattic.com/work-with-us/
- otec 12y agoMakefiles = crap
- MordodeMaru 12y agoHope to see it soon in biicode!
- banachtarski 12y agoWhy 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.