Re: [Boost-users] Networking TS + Beast, NEW Tutorials, Read this to learn std::net !!!

Subject: Re: [Boost-users] Networking TS + Beast, NEW Tutorials, Read this to learn std::net !!!
From: Stian Zeljko Vrba (vrba_at_[hidden])
Date: 2019-03-15 14:19:51

Sigh. A few comments from real-world experience.


>  We've had Asio for over a decade now, but there is a shortage of experts. Some people believe this shortage is because Asio in

particular (and thus, Networking TS since they have identical
interfaces) is "difficult to use."
>
> I believe it is wrong to blame Asio for this.

I disagree. Recently, I've been coding parallel, including networked & asynchronous, programs in C# and Java, and the experience has been a JOY. You get threads, executors, synchronization primitives, tasks, cancellation, monadic futures and concurrent (blocking and non-blocking) data structures out of the box with the platform, plus a myriad of extensions as libraries. As for executors, you don't need to be bothered with them unless you really want to for some reason.

In the beginning the C# program had 2 bugs (premature exit and deadlock) both of which were easy to find fix. This program has now hundreds of hours of heavy usage w/o bugs. It was easy and a joy to build thanks to the platform facilities.

In the java program I'm developing now, UI must be updated from "the UI thread". It took me whole *half an hour* to figure out how to write an executor that delegates execution to the UI thread and how to continue a completed future there (the flow is asynchronous network thread -> ui thread). All that just using the official JDK documentation, no external tutorials needed.


Compare the documentation for Vertx (vertx.io) or netty (both Java toolkits for writing asynchronous reactive programs) with that of asio.

On another C++ project, I had to roll my own.. basically everything built upon thread/mutex/cv and _unfortunately_ I decided to use asio for networking and serial ports. I feel dread every time I have to visit asio code and I regret I simply didn't use native Win32 APIs with direct callbacks. There are still native bits in there because Win32 natively supports cancellation of _synchronous_ blocking operations.

Once I attempted to write an asio service, tried to understand the simple example from the documentation, and I gave up. I used a thread, blocking call and CancelSynchronousIO (and I consider myself fortunate to develop for Windows only that has it).

Asio _is_ a relatively nice wrapper around socket and serial port APIs, but that's about it, IMO. On the other hand, I could have written the same wrappers around native APIs in two days and not haul along what I consider the baggage of technical debt that is asio in the codebase.

So now I'm regrettably stuck with asio for the forseeable future for two reasons: 1) laziness (i.e., writing the said socket/serial wrappers) and 2) need for timeouts and cancellation (just as well served by thread per client and CancelSynchronousIO). Lesson learned the hard way 😞

Conclusion, if any: many people just want/need thread per client and synchronous IO for simplicity, but until asio/networking TS provide for timeouts and cancellation of synchronous requests, it's a wrong tool for those people, me included.


-- Stian