• RPC for IPC on Same Machine: Using a full-featured RPC framework for IPC on the same machine may seem excessive. But if a project exposes RPCs for public APIs or benefits from a schema-based serialization layer, using one combined tool makes sense.
• FlashCam Architecture: For FlashCam on DAQ servers, it has a high-level architecture with each bright box as a software process. Processes directly talk to camera hardware via Ethernet. Some processes expose functions for others to call. The "State Supervisor" orchestrates subsystems and exposes an RPC interface. All processes send telemetry to a single collector.
• Microservices Benefits: Splitting subsystems into separate processes maximizes decoupling, allowing independent development, deployment, and testing. But it also has potential drawbacks like needing a common framework and monorepo.
• Why gRPC: gRPC was chosen for FlashCam as its default serialization layer (protobuf) is used in CTA. It provides efficient streaming connections and useful tooling.
• gRPC Latency for Local IPC: Measuring gRPC's unary call latency over Unix domain sockets shows it is about a factor of 10 slower than blocking I/O on different cores. But the ~100µs overhead is acceptable for the project.
• Conclusions: gRPC's overhead is outweighed by its benefits. The prototype telemetry collector can handle the expected message throughput.
• Literature: Performance best practices with gRPC and API design is stuck in the past are relevant.
• Code Appendix: Shows the code for running two microbenchmarks comparing Unix domain socket IPC and gRPC IPC.