#wire-protocol
Posts
-
Digging into Gradle's Source 3: From the gradle Command to the Daemon — the Launcher, the Wrapper and the Daemon Protocol
When you type gradle in a terminal, the build is not done by that process but by a daemon JVM hiding behind it. This post follows the 64 MiB client the shell script starts, the three paths that decide whether a daemon is used and what --no-daemon really means, how registry.bin is used to find a daemon and judge compatibility, the order in which a daemon is started and connected to, the 16-step command chain and the Idle/Busy states inside the daemon, the conditions under which a daemon stops itself, and how gradlew and IDEs reach the same daemon — all checked against the source at a fixed commit and with Docker examples.
-
Digging into Kafka's Source 3: The Wire Protocol — Requests and Responses Generated from JSON Schemas
The bytes a producer and a broker exchange over TCP always have one shape, [4-byte length][request header][body]. We follow in the source how 203 JSON schemas that define that shape become 391 Java classes at build time, how the ApiVersions exchange picks a version, and how flexible versions and tagged fields let old and new versions live together, then check the bytes ourselves with an example that sends requests over a raw socket using nothing but the generated classes.
-
Digging into MariaDB's Source 5: The Protocol and Command Dispatch — How One Packet Reaches dispatch_command
How the bytes a client sends become packets, how a single first byte decides between COM_QUERY, COM_PING and COM_STMT_EXECUTE, and how the result turns back into packets on the way out — followed through sql/net_serv.cc, do_command() and dispatch_command() in sql_parse.cc, and protocol.cc. We talk to the server directly over bash's /dev/tcp with no client library, and run the query cache to see why it can look up a result before the SQL is even parsed.