YangSiJun528 opened a new pull request, #2360: URL: https://github.com/apache/iggy/pull/2360
## Summary Adds a Wireshark dissector for the Iggy protocol to enable network traffic analysis and debugging. A new `wireshark` package contains a Lua-based dissector with integration tests for TCP protocol inspection and request-response matching. > [!NOTE] > This is a draft PR seeking feedback on the implementation approach before expanding coverage. ## Changes - `wireshark/dissector.lua`: Protocol dissector with Conversation API for request-response tracking and TCP desegmentation - `wireshark/tests/protocol_tests.rs`: Integration tests using tshark for live traffic capture and validation - `wireshark/README.md`: Setup and usage documentation Currently supports 3 commands: Ping, LoginUser, CreateTopic ## Known Limitations - Command coverage: Only 3 commands implemented - QUIC protocol: Not supported (TCP only, see note below) - Single-file dissector needs modularization for easier contribution - Requires local Iggy server running for tests - Only analyzes traffic to/from locally running servers - Missing implementation guide and architecture documentation ## TODO - Implement remaining 40+ commands - Refactor into modular structure - Improve test isolation with Docker Compose (similar to BDD tests) - Add implementation and architecture documentation - Support remote server traffic analysis ## QUIC Support QUIC support is excluded from this PR scope. While the binary protocol format is identical between TCP and QUIC (making dissector logic reusable), QUIC traffic decryption requires TLS session keys via `SSLKEYLOGFILE` environment variable ([Wireshark TLS Wiki](https://wiki.wireshark.org/TLS)). This would require: - Configuring rustls `KeyLogFile` in Iggy's QUIC implementation - Server core modifications with security considerations - Feature flag gating to prevent accidental production use Since TCP dissector validation is sufficient for protocol logic verification and QUIC can be easily added to tests later, QUIC support is deferred to future work. ## Questions for Reviewers 1. **Lua architecture**: I'm not sure if this is a common pattern, but I grouped request/response formats together in a single command table to make it easier to manage related information. Should this structure be refactored? 2. **Request-response ordering**: I implemented the dissector assuming Iggy supports request pipelining with strict FIFO ordering (unlike Kafka which allows out-of-order responses with correlation IDs). The dissector uses a queue-based tracker to match requests and responses in order. Is this assumption about Iggy's protocol behavior correct? 3. **Rust test approach**: Is the tshark-based integration testing appropriate? I initially considered using `BytesSerializable::to_bytes()` and SDK deserialization directly, but that felt too implementation-dependent and low-level for integration tests. Are there better testing approaches for this use case? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
