The Problem

Searching large text files over a network typically means either loading the entire file into memory on each request or shelling out to grep per query. Both approaches degrade under concurrent load. This repo provides a TCP server that keeps a searchable index of a text file and answers string-search queries from multiple clients concurrently, with SSL for transport security.

What This Does

The server (src/server.py) loads a text file once, builds one of several search indexes (set-based, memory-mapped, simple, regex, or system grep), and serves queries over a TCP socket. Clients connect via src/client.py, send a query string, and receive matching lines. The src/search_algorithms.py module holds the algorithm implementations and a factory (create_search_algorithm) that selects one based on config.

The repo also ships a benchmark harness (src/benchmark.py) that generates test files, runs each algorithm against them, and writes performance reports. A test suite in tests/test_server.py covers server behavior, algorithm correctness, and SSL handling.

How It Is Wired

Execution starts at main in src/server.py:599, which loads config, sets up the SSL context, and calls run_server_process. That spawns the server loop, which accepts connections and dispatches each to _handle_client_with_semaphore → _handle_client → search. The search function is the hub: 17 call sites route through it, and it reaches SearchResult 13 times and _check_test_case 5 times. server_instance_manager (12 call sites) and StringSearchServer (9 call sites) are the other high-blast-radius symbols.

The traced external effects are minimal: main → run_all_benchmarks → generate_test_file touches the filesystem via os.unlink, and _handle_client → search invokes subprocess.run (for the grep-based algorithm). That means the server's core query path does not leave the process except for grep mode. The module graph shows src/search_algorithms is a leaf (Ca 3, Ce 0), so it is stable; src/server sits in the middle with Ca 2, Ce 1.

File responsibilities: src/search_algorithms.py owns all search logic (16 functions, 8 classes). src/server.py owns the socket loop, SSL setup, and config parsing. src/client.py owns the client-side connection and SSL context. src/benchmark.py owns test-file generation and performance measurement. tests/test_server.py is the test suite (30 functions, 749 lines).

How To Use It

python -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
python -m src.server config/server.conf

Configuration lives in config/server.conf (INI format): [search] file_path, [server] host/port, [security] ssl_enabled/cert_path/key_path. Query with:

python -m src.client --host localhost --port 44445 --ssl true --query "search string"

Run tests with pytest tests/. A requirements.lock.txt exists for pinned versions.

Real-World Use

A log-aggregation sidecar: the server loads a daily log file, clients (other services) query it for error patterns or request IDs. The cached mode (reread_on_query=false) keeps the index in memory, so repeated queries on the same file are fast. The grep mode falls back to the system tool when a pattern is too complex for the built-in index.

Code Health & Issues

Static analysis (not opinion) found 7 findings: 5 high, 2 medium. The high ones are all deep nesting — src/search_algorithms.py, src/client.py, and src/server.py have max indentation depth 11, making control flow hard to follow. The medium findings are broad exception handling in src/search_algorithms.py (bare except swallows errors) and an oversized tests/test_server.py at 749 lines.

Beyond that: no CI workflow exists, no LICENSE file (README says "All rights reserved" — redistribution is legally blocked), and the 5.4MB 200k.txt test file sits in the repo root. The most serious operational issue is check_hostname = False in src/server.py's SSL setup — the connection is encrypted but the peer is not verified, so a MITM attacker can present their own certificate. Fix: remove that flag and point the client at the private CA bundle.

The Bottom Line

The search server itself is functional and the algorithm selection is sensible, but the codebase needs refactoring (deep nesting, broad exceptions) before it is pleasant to maintain. The SSL verification gap is a real security defect, not a style issue. Use this as a reference implementation or a starting point, not as production code as-is.