4 ms·

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

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.

synergy20 6y ago
what about POCO libs mentioned above for network and IO applications?
v8dev123 6y ago
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.
- nly 6y ago
  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/beast/ref/boost__beast__http__parser.html https://www.boost.org/doc/libs/develop/libs/beast/doc/html/b... [1] https://github.com/nodejs/http-parser/issues?q=is%3Aissue+author%3Avinniefalco+ https://github.com/nodejs/http-parser/issues?q=is%3Aissue+au...
  - secondcoming 6y ago
    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.
  - v8dev123 6y ago
    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
zvrba 6y ago
> 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.
nly 6y ago
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/beast/using_io/timeouts.html 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/websocket/server/chat-multi/ https://www.boost.org/doc/libs/1_70_0/libs/beast/example/web... [2] http://nghttp2.org/documentation/libnghttp2_asio.html http://nghttp2.org/documentation/libnghttp2_asio.html
- secondcoming 6y ago
  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.

synergy20 6y ago

what about POCO libs mentioned above for network and IO applications?

v8dev123 6y ago

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.

nly 6y ago
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/beast/ref/boost__beast__http__parser.html https://www.boost.org/doc/libs/develop/libs/beast/doc/html/b... [1] https://github.com/nodejs/http-parser/issues?q=is%3Aissue+author%3Avinniefalco+ https://github.com/nodejs/http-parser/issues?q=is%3Aissue+au...
- secondcoming 6y ago
  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.
- v8dev123 6y ago
  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

zvrba 6y ago

> 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.

nly 6y ago

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/beast/using_io/timeouts.html 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/websocket/server/chat-multi/ https://www.boost.org/doc/libs/1_70_0/libs/beast/example/web... [2] http://nghttp2.org/documentation/libnghttp2_asio.html http://nghttp2.org/documentation/libnghttp2_asio.html

secondcoming 6y ago
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.