Implementation and Evaluation of CYPHONIC client focusing on Sequencing mechanisms and Concurrency for packet processing

埋め込みコード

iframe
<iframe src="https://www.ren510.dev/slides/embed/implementation-and-evaluation-of-cyphonic-client-focusing-on-sequencing-mechanisms-and-concurrency-for-packet-processing/" title="Implementation and Evaluation of CYPHONIC client focusing on Sequencing mechanisms and Concurrency for packet processing" width="100%" style="aspect-ratio:1.778" frameborder="0" allowfullscreen></iframe>
script タグ
<script defer class="ren510-slide-embed" data-slug="implementation-and-evaluation-of-cyphonic-client-focusing-on-sequencing-mechanisms-and-concurrency-for-packet-processing" data-ratio="1.7777777777777777" src="https://www.ren510.dev/static/slides/embed.js"></script>
🤖 AI による要約 ✨
  1. P.1Title slide. Presentation at GCCE 2023 on CYPHONIC client implementation focusing on sequencing and concurrency for packet processing.
  2. P.2Presentation outline covering P2P communication solutions, CYPHONIC overview, challenges, objectives, proposed schemes, and evaluation.
  3. P.3Challenges for realizing P2P communication: NAPT traversal, IPv4-IPv6 incompatibility, and network security threats.
  4. P.4Overview of CYPHONIC. Virtual IP-based overlay network with AS, NMS, and TRS cloud services for device authentication and management.
  5. P.5Challenges of conventional client programs. State information coupled to processing modules prevents multi-threading. Single-threaded packet processing causes load concentration.
  6. P.6Research objectives. Proposal of multi-thread based asynchronous processing scheme focusing on concurrency and packet ordering mechanisms.
  7. P.7Conventional system overview. Signaling Module establishes overlay network, Packet Handling Module processes encrypted tunnel communication.
  8. P.8Conventional system model. Internal flow from DNS-triggered signaling initiation through packet handling via virtual network interface.
  9. P.9Proposed state information independence. Separation of state info from processing modules into an in-memory cache for multi-thread support.
  10. P.10Proposed multi-threaded packet processing. Transition from serial processing to dedicated worker threads for parallel decryption and decapsulation.
  11. P.11Implementation issues. Thread creation overhead, transaction identification across asynchronous modules, and packet ordering in multi-threaded processing.
  12. P.12Thread creation and allocation design. Pre-generated worker threads receive jobs from parent threads to avoid creation overhead.
  13. P.13Transaction handling in multi-threaded processing. Cache-based state information storage and retrieval for consistency across asynchronous workers.
  14. P.14Packet ordering mechanism. Packet Staging, Processing, and Sending modules maintain reception order during asynchronous capsulation and encryption.
  15. P.15Implementation details. Go 1.20 Goroutines with M:N scheduling model and event-driven architecture for efficient concurrent processing.
  16. P.16Verification environment. 10-node closed network setup measuring TCP/UDP throughput with iperf3 and RTT with ping.
  17. P.17Communication performance results. TCP and UDP throughput improved by 16.9 and 13.1 Mbit/sec respectively, with 4.0 ms delay improvement.
  18. P.18Application performance results. Proper heap memory release confirmed. OS threads remain constant while Goroutines scale with connections.
  19. P.19Conclusions. Proposed multi-thread scheme significantly improves throughput and maintains constant communication delay as connections increase.