I’m working on a big project that requires a server running sockets listening on a few ports for incoming clients. These sockets need to be running on for many weeks straight without failing, with client connections lasting anywhere between just a few minutes to maybe hours OR EVEN for the entire system uptime in rare cases.
I’ve read somewhere on these forums before that the sys sockets had some reliability issues and weren’t to be trusted maybe a few years ago, and I was wondering if this is still true today?
I’m mostly targeting the cpp, hl and web targets for my application, but the server which will listen on for long periods of time will be exclusively compiled for cpp.
When it comes to server side, I’ve personally tended towards using Node.js as TCP socket server, as opposed to Haxe, although the clients are Haxe (OpenFL targeting C++ and HTML5).
My main justification for that is the maturity of Node.js for that task, and it’s performance. It’s also quite easy to work with as a Haxe developer.
That’s not to suggest you should do the same, I’m just pointing to another option to consider. If you were to consider Haxe in the server role, I’d suggest stress testing a the server-side element yourself, to confirm it meets your expectations.
2 Likes
Not sure they’re unreliable per se. Just relatively low level and any IO errors are exceptions, so you’ll have to be careful to deal with those - and quite possibly not 100% the same way across targets / host OS. And because they use sync IO rather than event driven IO you’ll wind up rolling some threaded worker pool.
None of that is unsurmountable, but does require a fair amount of code. On cpp, there’s ThreadedServer, which does a fair amount of that work and should be quite portable. IIRC the original version was for neko, and was used by MotionTwin to power quite a few games.
1 Like