News for hackers. Stuff that matters.
Re:A Universal I/O Abstraction for C++ (2020) by secondcoming on Sunday April 18, 2021 @05:07PM (#26856370)
C++'s networking support is one of its greatest shortcomings. If I had the choice, I'd never use ASIO again and just use libuv.

Coroutines look interesting, I just need to get my head around them. All code examples I've seen, just as with ASIO, deal with the happy path only. For example, there's hardly a mention of timeouts and the faff ASIO makes you do to get them to work. If there's no 'read(..., timeout)' function then the API is broken as far as I'm concerned.

Then you'll (probably) need to write your own HTTP parsing code which, when you're half-way through, will make you realise that HTTP is actually not trivial at all to implement correctly. Best of luck writing your own HTTP2/3 engine. Boost.Beast seems like a great attempt at doing it right, but I've never used it. (HTTP needs to die, but that's a rant for another day)

IMO, it's too late for C++ and networking. If you need to read from something simple like a serial device then fine, it's probably ok. If you actually need to talk across the Internet then there are other languages that will do it better than you can.

Having said all this, personally, I know my limits and could never come up with anything better than ASIO.

Re:A Universal I/O Abstraction for C++ (2020) by nly on Monday April 19, 2021 @05:24AM (#26860684)
Boost Beast, which is built on ASIO, has support for timeouts[0], as well as HTTP 1.1 and Websockets. The examples in the Beast tree do do some pretty complex stuff elegantly, like a multi-client chat server[1], so it's possible.

There's also nghttp2_asio, built on nghttp2, which supports HTTP/2[2].

Overall I agree though that ASIO is a very complex and very low level, and it's a lot of work to use it well.

Sometimes it's easiest just to use libcurl.

[0] https://www.boost.org/doc/libs/1_76_0/libs/beast/doc/html/be...

[1] https://www.boost.org/doc/libs/1_70_0/libs/beast/example/web...

[2] http://nghttp2.org/documentation/libnghttp2_asio.html

Re:A Universal I/O Abstraction for C++ (2020) by secondcoming on Monday April 19, 2021 @07:20AM (#26861424)
We actually changed from libcurl to ASIO because libcurl creates a thread for every request, and it didn't handle concurrency well (I forget the exact details but it would crash if you added a curl handle to a curl_multi session if that session was already in progess)

Our use case sends thousands of requests per second per machine.

Re:A Universal I/O Abstraction for C++ (2020) by zvrba on Monday April 19, 2021 @01:05AM (#26859263)
> If I had the choice, I'd never use ASIO again and just use libuv.

Same here. I ported a legacy project from linux to windows, and continued to use ASIO (i.e., wrote new code) by inertia since the project already used it. Worst decision ever. If I could start from scratch, I'd just use raw Win32 APIs.

And I agree on HTTP(S). It has become an overcomplicated transport protocol on top of another transport protocol (TCP) and the only (though relevant) problem it solves is that it's allowed through most firewalls by default.

Re:A Universal I/O Abstraction for C++ (2020) by v8dev123 on Sunday April 18, 2021 @09:16PM (#26858252)
You might love evpp instead ASIO. It's just pain to install it but once you do it's a heaven.

As for HTTP parsing, llhttp does great job. It however lack multipart parsing.

Re:A Universal I/O Abstraction for C++ (2020) by nly on Monday April 19, 2021 @05:57AM (#26860905)
Boost.Beast has its own HTTP parser[0], during the development of which Vinnie Falco (the principle author of Beast) found many bugs/inconsistencies in Node.js's own parser[1].

Personally I'd rather use this than something based on Node.js http-parser.

[0] https://www.boost.org/doc/libs/develop/libs/beast/doc/html/b...

[1] https://github.com/nodejs/http-parser/issues?q=is%3Aissue+au...

Re:A Universal I/O Abstraction for C++ (2020) by secondcoming on Monday April 19, 2021 @07:10AM (#26861350)
We actually use the original node.js parser code (http_parser), which was originally based _I believe_ on the nginx parser. The Node people have since moved on to generating the C parser code with Typescript because the original code was too difficult to maintain (llparse).

Like I said, human-readable HTTP needs to die, but it's far too late.

Re:A Universal I/O Abstraction for C++ (2020) by v8dev123 on Monday April 19, 2021 @12:31PM (#26864649)
llhttp different from the original http-parser. It has lesser bugs because it's written in Typescript which transpiled to C and it's faster than the original http-parser
Re:A Universal I/O Abstraction for C++ (2020) by synergy20 on Sunday April 18, 2021 @06:21PM (#26857049)
what about POCO libs mentioned above for network and IO applications?