How jfpmonteiro/sok works
1. What this repository is
- sok is a small C codebase centered on a core socket-related library or abstraction in sok.c / sok.h.
- The rest of the tree is mostly test and example programs that exercise that core code in different network scenarios.
2. Core package boundary
- sok.h is the public interface boundary for the library.
- sok.c is the implementation boundary behind that interface.
- Any diagram should treat these two files as the central reusable component, with the test programs depending on them rather than each other.
3. Build and project orchestration
- The top-level Makefile is the primary build entry point.
- Each test subdirectory also has its own Makefile, so the repo is organized as a main library plus independently buildable test targets.
- doc.conf indicates there is a documentation/configuration layer separate from the build/runtime path.
4. Test suite structure
- tests/ contains three scenario-specific areas: simple, http, and rfi.
- These look like executable-level integration tests or demos rather than unit tests.
- The architecture should show them as clients/servers that validate the library under different protocol or transport conditions.
5. Simple test scenario
- tests/simple contains both client.c and server.c, plus a certificate.crt and privateKey.key.
- This strongly suggests a secure client/server handshake or encrypted transport example.
- The certificate and key are runtime inputs to the server side, so this folder represents a self-contained TLS-style test environment.
6. HTTP test scenario
- tests/http contains server.c and its own Makefile.
- This looks like a protocol-specific server example layered on top of the core sok functionality.
- In an architecture diagram, this is best shown as a higher-level application built on the socket layer, likely intended to demonstrate HTTP handling over that transport.
7. RFI test scenario
- tests/rfi contains client.c, server.c, and rfi.h.
- The presence of its own header suggests this test has an internal protocol or shared test-specific contract separate from the main library header.
- Treat this as another integration harness with a dedicated client/server pair and a small local API.
8. Data flow pattern
- The dominant runtime pattern is bidirectional network communication between a client process and a server process.
- The core library sits underneath these processes, providing the socket behavior they share.
- In the simple case, the server additionally depends on certificate material for secure setup.
9. Dependency layout
- Tests depend on the core library; the core library does not depend on test code.
- tests/rfi/rfi.h is local to that test subtree and should be shown as an internal helper boundary, not part of the public library API.
- The certificate and private key are deployment artifacts for the test environment, not code dependencies.
10. Likely repository intent
- This repo appears to be a compact networking library with example programs demonstrating usage across multiple scenarios.
- The examples are organized by protocol or concern rather than by layer, which is useful for an architecture diagram showing “core library” versus “scenario-specific executables.”
11. What to emphasize in a diagram
- Central reusable library: sok.c + sok.h
- Separate executable/test nodes: tests/simple, tests/http, tests/rfi
- Client/server communication paths
- Security assets in tests/simple as runtime server inputs
- Build boundaries via the top-level and per-test Makefiles
Main entry points: sok.h sok.h · Makefile Makefile · server.c Server · simple/Makefile Makefile
Components 14
Build & docs
Top-level build entry points and documentation configuration.
Core library
Reusable socket abstraction exposed by the public header and implemented in C.
Simple test
Self-contained client/server scenario with TLS-style runtime assets.
- Makefile · Build file for the simple scenario.
tests/simple/Makefile - Client · Client process for the simple scenario.
tests/simple/client.c - Server · Server process for the simple scenario.
tests/simple/server.c - Cert · Certificate material used by the simple server.
tests/simple/certificate.crt - Key · Private key material used by the simple server.
tests/simple/privateKey.key
HTTP test
Protocol-specific server example built on the core socket layer.
- Makefile · Build file for the HTTP scenario.
tests/http/Makefile - HTTP Server · HTTP-oriented server example on top of the core socket layer.
tests/http/server.c
Connections 17
- Makefile → sok.c: builds · Builds the core library implementation.
- Makefile → sok.h: installs · Exposes the public interface as part of the build.
- Makefile → Makefile: delegates · Top-level build can delegate into scenario-specific targets.
- Makefile → Makefile: delegates · Top-level build can delegate into scenario-specific targets.
- Makefile → Client: builds · Compiles the simple client executable.
- Makefile → Server: builds · Compiles the simple server executable.
- Client → sok.h: uses · Client consumes the public socket API.
- Server → sok.h: uses · Server consumes the public socket API.
- Server → Cert: loads · Server uses certificate material at runtime.
- Server → Key: loads · Server uses private key material at runtime.
- Makefile → HTTP Server: builds · Compiles the HTTP server executable.
- HTTP Server → sok.h: uses · HTTP server builds on the public socket API.
- Client → sok.h: uses · Client consumes the public socket API.
- Server → sok.h: uses · Server consumes the public socket API.
- Client → rfi.h: shares · Client uses the test-local contract header.
- Server → rfi.h: shares · Server uses the test-local contract header.
- sok.c → sok.h: implements · Implementation realizes the public interface.