知識マップ: シリアル通信アプリの落とし穴 - 再接続とログ設計まで

記事「シリアル通信アプリの落とし穴 - 再接続とログ設計まで」の主張を、概念と関係(エッジ)に分解した知識グラフの全体です。各関係には根拠・確認日・確度が付いています。

この記事は、装置連携などで使うC#のシリアル通信アプリで、たまにだけ壊れる不具合を防ぐための設計ガイドです。シリアル通信は順序付きのbyte streamにすぎずメッセージ境界を持たないため、DataReceivedイベントを1メッセージ到着の通知として扱うことは推奨されず、受信をいったん蓄積してからフレームパーサーで切り出す設計が推奨されます。送信は1本のワーカーに集約するsingle writerに寄せ、timeoutはopen・inter-byte・response・reconnect backoffという意味ごとに分けて設計します。フレームにリクエストIDが無いプロトコルでは応答のタイムアウト後に取り違えが起きうるため、単なる再接続ではなく受信バッファやparser状態まで作り直すセッション再生成が必要になります。

flowchart LR
    accTitle: シリアル通信アプリの落とし穴の知識マップ
    accDescr: シリアル通信がメッセージ境界を持たないbyte streamであることを起点に、フレームパーサーとsingle writer設計がその境界と送信順序をどう扱うか、timeoutの種別分割とリクエストIDの有無が応答の取り違えとセッション再生成にどうつながるかを示す図です。
    serial_communication["シリアル通信"]
    frame_parser["フレームパーサー(蓄積してから切り出す設計)"]
    single_writer["single writer(単一書き込み口)"]
    byte_stream["byte stream(順序付きbyte列)"]
    frame_boundary["フレーム境界"]
    datareceived_event["SerialPort.DataReceivedイベント"]
    crc_check["CRCによるフレーム検証"]
    inter_byte_timeout["inter-byte timeout"]
    timeout_taxonomy["タイムアウトの種別分割"]
    response_timeout["response timeout"]
    reconnect_backoff["backoff付き再接続"]
    response_mismatch_risk["応答の取り違えリスク"]
    request_id["リクエストID"]
    session_regeneration["session再生成(再接続設計)"]
    flow_control_lines["フロー制御・DTR/RTS"]
    hex_dump_logging["hex dumpを含む送受信ログ"]
    serial_communication -->|"利用する"| byte_stream
    byte_stream -->|"前提とする"| frame_boundary
    frame_parser -->|"実装を担う"| frame_boundary
    datareceived_event -->|"用いるのは非推奨"| frame_boundary
    frame_parser -->|"推奨される対応"| byte_stream
    single_writer -->|"推奨される対応"| serial_communication
    frame_parser -.->|"利用する"| crc_check
    frame_parser -.->|"利用する"| inter_byte_timeout
    timeout_taxonomy -->|"利用する"| inter_byte_timeout
    timeout_taxonomy -->|"利用する"| response_timeout
    timeout_taxonomy -->|"利用する"| reconnect_backoff
    response_timeout -.->|"原因になり得る"| response_mismatch_risk
    request_id -->|"防止する"| response_mismatch_risk
    session_regeneration -->|"推奨される対応"| response_mismatch_risk
    session_regeneration -->|"利用する"| reconnect_backoff
    serial_communication -.->|"前提とする"| flow_control_lines
    hex_dump_logging -->|"推奨される対応"| serial_communication
    single_writer -.->|"前提とする"| response_timeout

概念間の関係(全18件)

図と同じ関係を文章でも列挙します。表示している文と機械可読な意味データ(RDFa)は同じ要素に載っています。確度が「確立した関係」のものは直接の関係として、「条件付きの関係」のものは成立条件つきの言明(rdf:Statement)として表現しています。

シリアル通信はbyte stream(順序付きbyte列)を利用します。シリアル通信は順序付きのbyte streamであり、メッセージ境界は勝手には付かない / 確度: 確立した関係 / 確認日: 2026-08-01 出典
byte stream(順序付きbyte列)はフレーム境界を前提とします。byte streamからメッセージを取り出すには、フレーム境界をプロトコルとして自分で定義する必要がある / 確度: 確立した関係 / 確認日: 2026-08-01 出典
フレームパーサー(蓄積してから切り出す設計)はフレーム境界の実装を担います。フレームパーサーは、蓄積したbyte列からフレーム境界の定義に沿ってメッセージを切り出す実装を担う / 確度: 確立した関係 / 確認日: 2026-08-01 出典
SerialPort.DataReceivedイベントをフレーム境界に用いることは推奨されません。DataReceivedは受信byteごとに発火するとは限らないため、これを1メッセージ(フレーム)到着の通知として扱うことは推奨されない / 確度: 確立した関係 / 確認日: 2026-08-01 出典
フレームパーサー(蓄積してから切り出す設計)はbyte stream(順序付きbyte列)に対する本記事の推奨です。受信をいったん蓄積してからフレームを切り出す設計が、byte streamからメッセージを取り出す方法として本記事の推奨 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
single writer(単一書き込み口)はシリアル通信に対する本記事の推奨です。送信を1本のワーカーに集約するsingle writer設計が、シリアル通信での送信順序の崩れやコマンドの割り込みを防ぐための本記事の推奨 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
フレームパーサー(蓄積してから切り出す設計)はCRCによるフレーム検証を利用します。CRCを持つプロトコル(この記事が想定するヘッダ・長さ・payload・CRCのフレーム例)では、フレームパーサーは切り出したフレームの末尾のCRC値を検証し、壊れたフレームを捨てる / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
フレームパーサー(蓄積してから切り出す設計)はinter-byte timeoutを利用します。堅牢さを狙う設計では、フレームパーサーは組み立て中の候補が一定時間を超えたら諦めて再同期するinter-byte timeoutを持つ / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
タイムアウトの種別分割はinter-byte timeoutを利用します。タイムアウトの種別分割は、フレーム組み立て中に次のbyteが来ない時間を扱うinter-byte timeoutを含む / 確度: 確立した関係 / 確認日: 2026-08-01 出典
タイムアウトの種別分割はresponse timeoutを利用します。タイムアウトの種別分割は、コマンド発行から応答完了までを扱うresponse timeoutを含む / 確度: 確立した関係 / 確認日: 2026-08-01 出典
タイムアウトの種別分割はbackoff付き再接続を利用します。タイムアウトの種別分割は、再接続の待機間隔を扱うreconnect backoffを含む / 確度: 確立した関係 / 確認日: 2026-08-01 出典
response timeoutは応答の取り違えリスクの原因になることがあります。応答がタイムアウトしたあとそのまま次のコマンドを送ると、遅れて届いた前の応答が次のコマンドの応答として渡ってしまうことがある / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
リクエストIDは応答の取り違えリスクを防ぎます。フレームにリクエストIDを持たせて応答と突き合わせれば、遅れて届いた応答は知らないIDとして捨てられ、取り違えを防げる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
session再生成(再接続設計)は応答の取り違えリスクに対する本記事の推奨です。リクエストIDが無いプロトコルでは、応答がタイムアウトしたあとそのまま次を送らず、この接続を作り直すセッション再生成に落とすことが本記事の推奨 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
session再生成(再接続設計)はbackoff付き再接続を利用します。セッション再生成は、pending requestを失敗させたあとreconnect backoffの期間を置いてから再度ポートを開く / 確度: 確立した関係 / 確認日: 2026-08-01 出典
シリアル通信はフロー制御・DTR/RTSを前提とします。実機との通信では、RTS/CTSやXON/XOFFなどのフロー制御、DTR/RTSの設定を明示しておく必要がある。ソフトウェアのみのループバックやエミュレーションなど実機を介さない通信ではこの前提は当てはまらない / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
hex dumpを含む送受信ログはシリアル通信に対する本記事の推奨です。送受信時刻・ポート設定・送受信フレームのhex dump・parserエラー・応答の対応関係・再接続理由を残すログ設計が、通信障害の切り分けのために本記事が推奨する運用 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
single writer(単一書き込み口)はresponse timeoutを前提とします。request-response型のプロトコルでsingle writerを使う場合、そのワーカーは1件を送ったら応答が来るかresponse timeoutに達するまで次のコマンドを送らずに待つ。ログ書き込みのようなfire-and-forget用途のsingle writerにはこの前提は当てはまらない / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典

主要概念の定義

シリアル通信: 1本の通信路で順序付きのbyte列をやり取りする通信方式。メッセージの境界は自分でプロトコルとして定義する必要がある。
フレームパーサー(蓄積してから切り出す設計): 受信したbyte列をいったんバッファへ蓄積し、フレーム境界の定義に沿ってメッセージを切り出す受信側の設計。
single writer(単一書き込み口): 呼び出し側が何スレッドあっても、書き込み先(ログファイルやシリアルポートなど)への実際の書き込みは1か所(1スレッド)だけに絞る設計。
byte stream(順序付きbyte列): 送受信の順序だけが保証され、メッセージの境界を持たないbyteの列。1回の書き込みが受信側では分割されたり連結されたりして届く。
SerialPort.DataReceivedイベント: .NETのSerialPortが提供する受信通知イベント。受信byteごとに発火するとは限らず、UIスレッドでもない。
タイムアウトの種別分割: open・inter-byte・response・reconnect backoffなど、意味ごとに分けて設計するタイムアウトの考え方。1個の数字で全部を表現しようとすると原因の切り分けが難しくなる。
response timeout: コマンド発行から応答完了までを打ち切るまでの時間。
リクエストID: コマンドとその応答を一意に対応づけるための識別子。フレームに持たせないと、遅延応答を次のコマンドの応答と誤認するおそれがある。
session再生成(再接続設計): 受信バッファ・parser状態・pending request・初期化シーケンスまで含めて作り直す再接続の設計。単なるOpen()のやり直しでは足りない。
hex dumpを含む送受信ログ: 送受信時刻・ポート設定・送受信フレームのhex dump・parserエラー・応答の対応関係・再接続理由を残すログ設計。

機械可読データ

JSON-LD / Turtle ── この記事の知識グラフ全体
概念一覧 / 語彙(述語)の定義

このページはサイトの知識グラフ(_data/knowledge/)から自動生成されています。誤りの指摘はお問い合わせからお願いします。