C++ network code helper

Describe the networking job. Get C++ Boost.Asio code that compiles on your version of Boost.

C++ network code helper is a free AI skill for the job "Build and ship software". Give the instructions to an AI assistant that supports the required files and tools, then review its output.

Free · No account · MIT licence · Made by Alireza Rezvani · Level: expert · Thinking: high

Start this task

Download the complete instructions and supporting files. Add the material the task needs in an AI that supports those files and tools.

Download all files

Made by Alireza Rezvani. See the original on GitHub; we copied it as it is, with its licence.

What it does

C++ network code that actually compiles on your version of Boost. Describe the job, such as a server, client, timer or secure connection, and you get working asynchronous code in the style your setup supports. Most Asio examples online are old and fail on new toolchains, or use coroutines that old compilers cannot build. So the skill checks your Boost version and C++ standard first, then picks one of the styles: coroutines, callbacks, or stackful spawn. It follows a reference file for that style. The three worked examples it relies on were tested across Boost releases from 2016 onward. You need a C++ build setup to try the results.

You give it

The networking job you want done
Your Boost or Asio version
Your C++ standard and build tool (optional)
Existing code to review (optional)
Codebase (optional)

You get

Async C++ code in the right style for your version
A server, client, timer or secure connection example
Notes on why that style was chosen
Build hints for your setup

Use it when

You are writing a TCP server and your compiler rejects the example you found.
You need a timer or client in C++ that fits an older Boost version.
You want to add TLS to a connection and are not sure which API to use.
You are reviewing async network code that mixes old and new styles.

More for Build and ship software

Every build and ship software skill

Full instructions

Add it to your AI once: download it and add the folder to Claude, ChatGPT or Codex as a skill.
Ask for the job in your own words. Your AI opens the skill when it fits.
It works best when your AI can run code and read your project files.

Full instruction file

Boost.Asio / standalone Asio

Overview

Write async C++ networking code that compiles on the user's Boost, not the newest one. Asio's API changed shape three times (classic io_service → io_context → C++20 coroutines) and most Asio code on the internet is from the first era, so pick the style from the toolchain first, then follow that style's reference file.

References: Boost.Asio · standalone Asio

Use this skill whenever async C++ networking code is being written or reviewed — and especially when the target toolchain is old, where coroutine examples simply will not compile. The three worked implementations it references are CI-verified from Boost 1.62 (2016) through 1.90.

Step 1: pick the style (do this before writing code)

Determine the Boost (or Asio) version and the C++ standard actually in use — find_package(Boost) output, dpkg -l libboost-dev, brew info boost, CMAKE_CXX_STANDARD, or ask. Do not assume the newest.

Boost	C++ std	Style	Read
≥ 1.77	C++20	Coroutines (`co_await` + `awaitable<T>`) — preferred	references/coroutines.md
≥ 1.74	C++11–17	Completion handlers (callbacks) — the portable baseline	references/pre-cpp20.md
≥ 1.80	C++11–17	Stackful `asio::spawn` + `yield_context` (links Boost.Coroutine — not header-only)	references/pre-cpp20.md
1.62–1.65	C++11	Classic `io_service` / `strand.wrap` / `expires_from_now`	references/classic-boost.md

SSL/TLS in any style: references/ssl.md. CMake for any style: references/build.md.

io_context, make_strand, bind_executor, steady_timer, signal_set, async_read/async_write/async_read_until, buffers and resolver are library features — identical in the coroutine and callback styles. Only the suspension mechanism differs.

Step 2: version floors (verified by compiling, not from docs)

Reach for one of these and the build breaks on older distros:

Feature	Floor
`experimental/awaitable_operators.hpp` (the `\|\|` / `&&` operators)	Boost ≥ 1.77 / Asio ≥ 1.20
`as_tuple` completion token	Boost ≥ 1.79 / Asio ≥ 1.21
`co_composed` (custom composed ops)	Boost ≥ 1.85 / Asio ≥ 1.30
3-arg `asio::spawn(ex, fn, token)`	Boost ≥ 1.80 (older Boost has only `spawn(ex, fn)`)
`any_io_executor` (`strand<any_io_executor>`, `tcp::socket`'s default executor)	Boost ≥ 1.74 — the floor for the callback style; below it, use legacy `io_context::strand`
`io_context`, `make_strand`, `expires_after`	Boost ≥ 1.66 — below it, classic `io_service`

Distro floors that bite: Debian bookworm ships Boost 1.74 (no awaitable_operators.hpp — #include fails outright), Ubuntu 20.04 ships 1.71 (no any_io_executor), Debian 9 ships 1.62.

Language, not library: the chrono literals 250ms / 30s are C++14. For a true C++11 build write std::chrono::milliseconds(250).

Step 3: the rules that are actually easy to get wrong

A strand does not serialize writes. A strand serializes handler execution, not whole composed operations. Two async_writes in flight on the same strand still interleave bytes on the wire. Full-duplex (a read loop plus concurrent pushes/replies) needs a per-connection strand and an outbound queue with an in-flight flag, so at most one async_write exists at a time. This is the single most common wrong answer about Asio.

Buffers do not own memory. asio::buffer() is a view. Storage must outlive the operation: coroutine locals are fine across co_await in the same frame; in callback style the same data must become a member, not a local.

Connections must outlive their handlers. enable_shared_from_this, and capture self in every co_spawn / handler — read loop, write loop, and each timer.

Frame with composed reads. async_read (fills the buffer exactly) for a length prefix and then the body; never async_read_some, which returns short.

Wrap as_tuple. Always as_tuple(use_awaitable). Bare as_tuple resolves against the operation's default token and compiles in some contexts, fails in others.

async_accept(make_strand(...)) changes two things: it forces an explicit completion token back on the call, and the accepted socket is basic_stream_socket<tcp, strand<...>>, not tcp::socket. Take it by value or with auto — binding it to tcp::socket& will not compile.

Re-arming a timer resolves the pending wait with operation_aborted. In an idle-timeout loop that is the signal to keep waiting, not an error.

GCC needs -fcoroutines for the C++20 style, and header-only Boost needs BOOST_ERROR_CODE_HEADER_ONLY defined in exactly one place (CMake).

Anti-Patterns

Mistake	Fix
Buffer dangling (local goes out of scope during async op)	Ensure buffer lifetime ≥ operation lifetime; coroutine locals or members, not callback locals
Forgetting `io.run()`	No handlers dispatch without `run()` / `run_one()`
Concurrent socket access without strand	Wrap in `strand<>` or serialize via one coroutine chain
Assuming a strand prevents interleaved writes	Add a write queue — see Step 3
Using `use_awaitable` where `deferred` suffices	Omit the token (default is `deferred`) unless using `\|\|` / `&&`
Ignoring short reads/writes	Use composed `async_read` / `async_write` / `async_read_until`, not `async_read_some`
Not setting `reuse_address` on the acceptor	Set before `bind`/`listen` or restarts hit "address in use"
SSL operations without a strand	All `ssl::stream` ops need strand synchronization
Blocking inside a handler	Never block in a completion handler
Accepting a socket with the wrong executor type	See `async_accept(make_strand(...))` in Step 3
Requiring the `Boost::system` component	Header-only since 1.74: `Boost::headers` + `BOOST_ERROR_CODE_HEADER_ONLY`. Only classic (pre-1.66) needs the link
Missing `-fcoroutines` on GCC	Build fails — add `$<$<CXX_COMPILER_ID:GNU>:-fcoroutines>`
Writing coroutine code for a Boost that predates it	Do Step 1 first

Boost.Asio vs standalone Asio

Same author, same API — namespace and includes differ.

Aspect	Boost.Asio	Standalone Asio
Namespace / include	`boost::asio` / `<boost/asio.hpp>`	`asio` / `<asio.hpp>`
Error code	`boost::system::error_code`	`asio::error_code` (or `std::error_code`)
Install (brew)	`brew install boost`	`brew install asio`
CMake	`Boost::headers`	manual include path
Version (2025)	1.87–1.90 (with Boost)	1.30–1.36 (independent)
Macro prefix	`BOOST_ASIO_`	`ASIO_`

Support both with a shim, then use net:: throughout:

#ifdef USE_STANDALONE_ASIO
  #include <asio.hpp>
  namespace net = asio;
  using error_code = asio::error_code;
#else
  #include <boost/asio.hpp>
  namespace net = boost::asio;
  using error_code = boost::system::error_code;
#endif
namespace ssl = net::ssl;
using tcp = net::ip::tcp;

Before you call it done

Check the code you just wrote against this list:

Style matches the target Boost version and C++ standard (Step 1), and every API used clears its floor (Step 2).
Every buffer passed to an async op outlives that op — no callback locals, no dangling string_view.
At most one async_write per socket in flight, enforced by a queue + flag, if anything writes concurrently with reading.
Every async chain on a shared object runs on the same strand; self captured in every handler and co_spawn.
Framing / delimited reads use composed async_read / async_read_until.
Errors are handled, not swallowed: as_tuple(use_awaitable) destructured, or the callback's ec checked, on every op.
operation_aborted distinguished from real errors wherever a timer is re-armed or an op is cancelled.
Acceptor sets reuse_address; shutdown path closes the acceptor and drains sessions.
CMake has the standard, -fcoroutines for GCC (C++20 only), BOOST_ERROR_CODE_HEADER_ONLY in one place, and Boost::coroutine only if using stackful spawn.
It compiles. Build it — most of the mistakes above are compile-time, and the version floors are only real once tested.

Worked examples

Three CI-verified implementations of the same full-duplex framed-protocol server, one per style — copy from the one matching Step 1. All three live in the upstream repository and are built by CI on every push.

market-data-feed — C++20 coroutines (Boost 1.77+; verified 1.83–1.90)
market-data-feed-precpp20 — callbacks, C++11-clean (verified Boost 1.74+, incl. Windows/MSVC)
market-data-feed-classic — classic io_service (verified back to Boost 1.62 / Debian 9)

Official documentation

Cross-References

engineering/docker-development — the old-Boost verification lanes this skill's floors come from are containerised builds (Debian 9 / bookworm, Fedora).
engineering/chaos-engineering — for exercising the failure paths this skill tells you to handle: half-open sockets, idle timeouts, partial frames.
engineering-team/playwright-pro — the client-side counterpart when the server built here is driven from browser-based integration tests.