ポジローぽけっと

昨日より今日、今日より明日を信じて、トライトライ

第六十三回スパルタンプログラミング

スパルタンプログラミング

やったこと

12/05

  • 小渡チャリトレ、08:00-11:15。往路のスピードがどうやっても落ちる。登りでキタムーに負け越さなくなってきた。減量の成果かな。
  • 洗濯して、飯食って、移動。
  • Connection Errorのハンドル関数の実装
    • 漏れがないように実装する
      • 済 3.5 不正なコネクションプリフェイス protocol_error, goaway 省略化
      • 済 4.2 SETTINGS_MAX_FRAME_SIZE で定義されたサイズやフレームタイプで定義された制限を超えていたり、必須となるフレームデータを含むには小さすぎる要な場合、FRAME_SIZE_ERROR
      • 済 4.3 ヘッダーブロックのデコードエラーは COMPRESSION_ERROR のコネクションエラー
      • 済 5.1 idle 状態のストリームでの HEADERS や PRIORITY 以外のフレームの受信は、PROTOCOL_ERROR のコネクションエラー
      • 済 5.1 reserved local 状態のストリームでの RST_STREAM や PRIORITY、WINDOW_UPDATE フレーム以外の受信については、PROTOCOL_ERROR のコネクションエラー
      • 済 5.1 resserve remote 状態のストリームでの HEADERS や RST_STREAM、PRIORITY フレーム以外の受信については、PROTOCOL_ERROR のコネクションエラー
      • 5.1 closed END_STREAM フラグが設定されたフレームを受信した後に、さらにフレームを受信したエンドポイントは、以下の説明にあるような許可されたフレームでない限り、STREAM_CLOSED のコネクションエラー
  • 送信時にchangestreamstateが呼べてない。

12/06

  • 帰社のための移動日
  • やりたいことってなんだったっけ？
    • 5.1対応->connection errorとstream errorのhandling->フレーム処理のロジックにhandlingの関数を実装したいが、フレーム処理ロジックが動けばいいや状態でくちゃくちゃ
    • まず、フレーム処理ロジックを整理したい。そのためにロジックのステートマシンを書いて整理する。
  • フレーム処理ロジック
    • フレームタイプのチェック->フレーム毎の処理に対して仕様が要請する制約はあるか？
      • Headerの場合、END_STREAM, END_HEADERSがそれに当たる。
  • ステート管理ロジック
    • ややこしいのをなんとかしたい。

12/07

  • 帰社日。出向元会社の所属部署と査定部署が異なる。なぜだ。
  • headerが来てないのにcontinuationが来たらエラー
    • どうやって記憶させるか、streamにひもづく、end_streamなどのフラグをstream構造体に保持させる？
      • どこまで調べきれば、実装を決められる？何がネック？ これはストリームの状態遷移が正しく管理できれば必要ない可能性がある。よって、まずそれの適正化。←今ココ
    • ストリームの状態遷移管理はフレームの受信時は、送信時はEnqueue後に行う。

12/08-11

  • ノーコード。減量は順調。