# システム内部仕様 AtCoder Next 内部に実装されている主要な仕組みについて、実装背景も含めて解説します。 --- ## レートリミッター（漸近遅延方式） AtCoderサーバーへの負荷を抑え、意図しないアクセス制限（BAN）を避けるため、アクセス頻度に応じて遅延時間を動的に調整するレートリミッターを実装しています。 基本的な考え方は次の2点です。 - 連続してアクセスするほど遅延時間が増加する - アクセス間隔が空くと、ペナルティが時間経過とともに回復する 具体的な処理は以下の通りです。 **(1) 経過時間による回復** 前回アクセスからの経過秒数に回復レート`recoveryRate`を掛け、その値を連続アクセスのカウントから減算します。これにより、間隔を空けるほどペナルティが自然に減っていきます。 **(2) 遅延時間の算出** 連続アクセス数の増加に伴い、遅延時間は最小値`minDelay`から最大値`maxDelay`に向かって増加します。単純な線形増加では機械的なパターンとして検知されやすいため、シグモイド関数に近い曲線を用いて漸近的に増加させています。 **(3) ジッターの付与** 算出した遅延時間に対し、ランダムに±10%程度のゆらぎを加えています。固定的な周期パターンとして検知されることを避ける目的です。 **(4) 状態の永続化** 最終アクセス時刻と連続アクセス数は `~/.atcoder-next/state.json` に保存しています。これにより、複数のターミナルから同時にコマンドを実行した場合でも、プロセス間でアクセス制限の状態が共有されます。 **(5) リクエストの直列化** 非同期に発行された複数のリクエストが並列に送信されないよう、JS内部でグローバルなPromiseキューを用いて直列に処理しています。 --- ## 提出後のポーリング（指数バックオフ） コード提出後、ジャッジステータス（WJ、AC、WA など）の更新を監視するポーリング処理では、状況に応じて間隔を動的に調整しています。 - ステータスに変化がない間は、ポーリング間隔を毎回1.5倍に延長します（初期値2.0秒、最大10.0秒）。長時間の待機中にサーバーへ不要な通信を送り続けることを避けるための措置です。 - ステータスに変化が生じた場合（例：WJ から「1/15 判定中」への更新など）は、間隔を即座に最小値の2.0秒へリセットします。変化が活発な期間は、可能な限りリアルタイムに近い追従を行います。 --- ## セッション情報の保護 ログイン情報（Cookie）をローカルに保存する際のセキュリティ対策です。 - Cookie情報は平文では保存せず、AES-256-CBCで暗号化した上で `session.json` に書き込んでいます。 - **OSキーチェーンとの統合**: 暗号化に使用する32バイト鍵は、まず各OS標準のキーチェーン（macOS Keychain、Windows DPAPI、Linux Secret Service）へ優先的に保存・取得を行います。 - **安全なフォールバック**: ヘッドレスLinuxやCI環境などキーチェーンが利用できない環境では、`~/.atcoder-next/.key` ファイル（パーミッション `0o600`）へ自動的にフォールバックして読み書きを行います。 - セッションファイル `session.json` は、生成時点でパーミッションを `0o600`（Windows環境では同等のACL）に制限しています。 --- ## 4. ディレクトリトラバーサル対策 解答ファイルを1つにまとめるバンドル処理（`atc tools bundle`）では、意図しないファイル読み込みを防ぐため、境界チェックを実装しています。 - 依存関係を解決する際、解決後のすべての絶対パスがワークスペースルートの配下に収まっているかを検証します。 - `..` による相対参照や `/etc/passwd` のような絶対パス指定によってワークスペース外へアクセスしようとした場合は、処理を即座に中断し、`Access denied: File is outside the workspace root.` というエラーを返します。 --- ## 5. バンドル処理のインプロセス化 TypeScript/JavaScriptのバンドル処理（`tools bundle`）では、esbuildをCLI経由の子プロセスとして起動するのではなく、ライブラリとして直接読み込み、Node.jsプロセス内で `esbuild.buildSync` を呼び出しています。 これにより、子プロセス起動に伴う数十〜数百ミリ秒程度の遅延が発生せず、バンドル処理を短時間で完了できます。