仕様.txt

+----------------+
|△ 未確認       |
|□ 未完了       |
|▲ 動作未確認   |
|■ 完了済       |
|× 実施しない   |
+----------------+

・自動観戦
・ロールバック方式
・ネットダイア

□ リプレイファイル共有
　 リプDLの為だけにサーバーを使いたくない
　 プラクティスのリプレイに対応できれば
　 コンボムービーとかにもつかえるかも

□ resync機能
　 syncエラー発生時に試合中に変化する情報をすべてどちらかに一致させる
   すべてといっても
   現状のsyncチェックでは不十分、どの程度実用的なのか不明
　 チート対策が必要
   位置補正だけで解決するかどうかやってみる
　 多すぎる移動はありえないのでSyncErrorを検出したら+-7の範囲でResyncする

■ 低速化対策①
   PingRepでは対戦情報を送らない
   BattleInfoメッセージを新規に作成し、
   メニューを開いた時に要求を送る
　（取得できたら保存して以後送らない。Idleになったらその情報をクリアし、
　　再びBusy(Casting)になった時にまた要求を出すようにする）
   先にWatch/Idleノードに対して要求し、情報が得られなければBusyに直接問い合わせる
   Watchは実際にその試合を観ていた場合、Idleはその情報を既に取得している場合に取得が可能。

  確認項目
　・Busy(Casting)[W]のメニュー開いた時に情報が表示されること
　・既に情報取得済のIdleノードがいる時、そちらが優先される
　・観戦しているノードがいる時、そちらが優先される。
　・前の観戦者が残っている時に、情報を取得すると前の観戦者は無視されるか？
　・誰からも取得できなかった場合の動作について

SPacket_BattleInfoRequest
{
  char    targetName[30]
  in_addr targetIP
  int     targetGameCount
}

SPacket_BattleInfo
{
  char name[2][30]
  char chara[2]
}

□ rootに直接つなぎにいく時、相手が空いてるのに繋がらない
　 空いてる本人に直接つなげば繋がる
   相手の情報提供に問題があるケース？

■ 圧縮データが混在するとデータが破損する
　 接続＞すぐに切断＞再接続で高確率で発生
   オフセットを更新するようになったので別のデータを受信している可能性が高い

■ 普通に通信してても途中で突然切れることがある
　 圧縮をOFFにしてみて問題を切り分ける
   上記２点共にTesterでは確認できない。

■ 同期チェッカの観点を増やし原因を究明する
   特にアクションIDやフレーム値、位置情報などが有効と思われる
   とりあえずローカルで再現させないことにはどうしようもない
■ WatchDataReplyが１度でもロストすると切れてしまう
■ 圧縮データのバッファリング中に停止することがある
■ 圧縮データの観戦時にクラッシュする不具合（メモリ破壊の可能性）
■ 今回せっかくコメント送信を分けたので可変長に対応しておく
　 （256byte程度の文字列では圧縮は無意味だった）
■ 観戦データの圧縮に対応すべき
   圧縮したものを分割して送り、受信側では不完全のままでも随時展開する
   圧縮データの続きを他のノードから受信するのはやめる
   SendCompWatchDataを新しく作成。
   無理やり展開すると1フレーム単位で展開されるわけではない。
　 （４バイト境界に切捨てで合わせること！）
■ Bufferingで接続ロストすると固まる（キャンセルが必要）
■ 観戦ノードの再接続が永久に行われていた不具合
■ ロビーのGalleryCountが安定しない不具合
■ 観戦者数が安定しない（新参観戦者によるノイズが原因か？）
■ iniファイルでignore Slow Connectionを復活
■ ロビーの色変えを拒否優先
■ 観戦時に設定の合わないノードから接続されてしまう問題
 ・観戦中はPingを計らないので要求があれば無条件に接続されてしまう。
   毎回ping値を正確に出せていれば古い値を使ってチェックするのもいい
 ・PingRepLiteが肥大化している
 >>観戦オフの場合前のVersionのままで問題ないか？（観戦は可能か？）
　 無理なら本当のPingRepLiteを別に作る
■ まともな数値のpingが期待できるようになると思うので、watch中も今まで通りpingチェックすること！
□ 不完全なリプはincompleteとか付ける？(過去に挙がっていたが忘れていた)
□ 離れすぎたランクの乱入を拒否オプション(+-4くらいが妥当か)

△ オプションで動的に変えてもいい情報は何だ？
　 ディレイとか今のままじゃ絶対無理
■ cidが異なる場合、ちゃんとVersionErrorになるのか？
   nodeにcid持つ必要あるのか？
   
■ 速度低下対応
  busy中のpingrepの肥大化が一員になっていると思われる
　対処としては対戦情報をWatchから送るようにする
　未取得の場合、メニューを開いた時に対戦情報要求を出す（Watchが一人もいない場合等で起こりえる）
　
　pingrepで状況別に必須なものをまとめる。それぞれ別の構造体にする方法で考えている
　ver[10]の有無でnoinfo扱いにしている箇所は見直しが必要！（idcmpで検索しろ！）
　（noinfoのときpingを----にしているのでソートでおかしくなっている件についても調べておく）
　既存のpingrepをすべてやめ、commentは別に送る
　
	busy(casting)
		watchFlags	: 不要(観戦していないことが伝わればいい)
		watchMaxNode: 不要(ロビー表示で使用しているが、無くても判断可能)
		gamecount	: 必要(観戦の試合の照合のため)
		deny		: 不要(観戦は拒否できない仕様)
		round		: 不要
		delay		: 不要
		ex			: 不要
		wins		: 必要(観戦の基準となるのであったほうがいい)
		rank		: 必要(観戦の基準となるのであったほうがいい)
		id[10]		: 不要(単に拒否できなくなるだけ)
		ver[10]		: 不要
		name[2][30]	: 検討中(watchからの情報をbusy(casting)に設定するようにした場合は不要。ただし別途対戦情報要求に応じる必要がある)
		chara[2]	: 検討中(watchからの情報をbusy(casting)に設定するようにした場合は不要。ただし別途対戦情報要求に応じる必要がある)
		busy		: 必要(ただしCASTING_OK/NGが解ればよい)

	busy
		watchFlags	: 不要(観戦していないことが伝わればいい)
		watchMaxNode: 不要(ロビーで表示できなくなるだけ)
		gamecount	: 不要
		deny		: 不要
		round		: 不要
		delay		: 不要
		ex			: 不要
		wins		: 不要
		rank		: 不要
		id[10]		: 不要(単に拒否できなくなるだけ)
		ver[10]		: 不要
		name[2][30]	: 不要(あるならあったほうがいいが、どうせ観戦できないので不要)
		chara[2]	: 不要(あるならあったほうがいいが、どうせ観戦できないので不要)
		busy		: 不要(busy一択なので)

	watch (観戦中の乱入のせいで必要な情報が多くなっている。特にenemyInfoに設定するものは必須)
		watchFlags	: 必要(乱入許可するかどうかだけでいい。構造体を分けるならそれすらも不要)
		watchMaxNode: 必要(enemyInfoに設定する)
		gamecount	: 必要(enemyInfoに設定する)
		deny		: 必要(乱入許可判定で使用)
		round		: 必要(enemyInfoに設定する)
		delay		: 必要(乱入許可判定で使用)
		ex			: 必要(enemyInfoに設定する)
		wins		: 必要(enemyInfoに設定する)
		rank		: 必要(enemyInfoに設定する)
		id[10]		: 必要(乱入許可判定で使用)
		ver[10]		: 必要(enemyInfoに設定するために必要)
		name[2][30]	: 検討中(watchからの情報をbusy(casting)に設定するようにした場合は必要)
		chara[2]	: 検討中(watchからの情報をbusy(casting)に設定するようにした場合は必要)
		busy		: 不要(旧verでbusy扱いすることにだけ注意)

	idle
		基本的に対戦時の情報が要らない
　　　　一度pingrepfull版で送っているので動的に変化し得る情報だけでいい
　　　　起動中のオプション変更にも対応できるように(ex、round設定等)

--------------------------------------------------------------------------------------
■ 観戦中に乱入されるとEXがONにならない
■ 1.対戦終了 > 2.観戦者観戦中 > 3.配信者が新しい対戦開始 > 4.新しく観戦すると2がヒットして古いデータが配信される
■ デバッグ用に観戦受付を一時的に拒否する機能がほしい
■ 観戦中にノイズが入る問題->データ構造変える際にエンバグしていた
■ 観戦者数集計について
　 watcherに子孫の合計を格納するメンバが必要。
　 親への要求時に自分の子孫の申告数を合計し報告。
　 親から入力データを受け取る際に配信元から来た観戦者数をそのまま子へ伝播する。
　 配信元間のキーデータとは別に観戦者数を報告しあうメッセージを新規に作成（再送不要で頻度も低めでよい）。
■ ロビーの観戦者数表示
   観戦者はロビーにいるノードからのPingを返す際に、PingRepLiteとは別のメッセージとして
　 観戦者数と配信元両者のIPと名前を送信。各ノードはそれを観戦者数としてロビーに表示。
■ PingRepLiteに情報を追加し、誰と誰が戦っているかわかるようにしたい。
■ ロビーにGalleryを追加
　 Enable BroadcastがOFFなら常に"---"
　 Busy(Casting)[白]の場合のみ観戦者数をここに表示。（Watchソートでは観戦者数順にソート）
■ 観戦データサイズを変えても互換が取れること
■ 最低５ノードでの４次接続までテストすべき
　 ２次が抜けて３次が再接続される時、４次はどう動く？
× 配信元に拒否られているとwatchも不可能
   まともにチェックするのは大変なので
　 拒否している者から直接つながらないだけでいい
× playが終了してもwatchDataを継続可能か？
　 過去のデータが混ざるのだけはまずい
　（次の接続開始時には強制切断してもいい）
△ １次配信＜ー＞観戦との接続エラーの確認
△ 最後のほうで観戦を始めると最後まで受信できないケースが十分ありえる
　 データが多いときだけ圧縮したものを送るようにする
△ CS決定時にpaletteをアップデートするか
△ pinfoが拡張可能ならlowspecオプションも送りたい。
× 観戦が有効かどうかは相手との受付数の合計が１以上かどうか
　 Packet_Connectでやり取りすればよいか？
× replayバッファを２つ持って交互に使えば対戦終了時の強制切断はまず起こらない
　 対戦をちゃんと照合可能かどうかの問題
× リプレイ観戦時早送りのまま終了すると再度再生されてしまう
■ Enable Broadcastを許可／拒否の用途で使用する
　 許可するが回線が細く、自分では配信できない場合、MaxRelayNode(Play)を0に設定する
   今はCasting白になってしまっているのでそれを修正
　 Max Relay Node(Play)　　0-2
　 Max Relay Node(Watch)　 1-4
■ Watch中サーバーから名前が消える問題
   開いているのに中継ノードが機能しないことがある原因になっている
■ やはり観戦拒否オプションも必要
■ 新しいStatusのソートを考慮する
■ 自分がBC=Offでも相手がOnならBusy(Casting)であること。
   互いにOffの場合に限り、Busyとなり観戦できない。
   相手の情報を取得前にBusyとして送られてしまうと
　 以後、pingのやり取りをしないので永久にbusyのままになる
   対策としてwatchIn時に応答がなかったらNoResにする
　 pingReplyLiteでbusyを返すのはenemyの情報を取得できてからにする
　 enemyinfoが未取得だったらNotReadyにでもしておく
■ 観戦中だと乱入許可フラグがセットされない
■ 観戦リプを保存しない設定
■ 観戦データが途中で切れるとソフトリセット扱いになる
■ キャラセレで切断したリプを再生するとクラッシュする
　 サイズがヘッダ以下の場合は保存しないようにする
■ データ共通化するためにはsavedata.datを動的に判断しなくてはならない
   各種生成されるファイルがexeのあるディレクトリに生成されること
■ 子が再接続先で途中からデータ受信できるか？
　 ２次観戦側で配信元が設定されないので動かないはず。対応が必要
■ リアルタイム観戦状態にすると観戦側でやたらとガクガクする
　 早送り制限で対応
■ Casting中にESC押されたりするとCastingのままロビーに残ってしまう
   (Busyも同様の現象があるがBusyに対して行う操作がないのでそれほど問題はない。
　 一方、Castingは観戦可能なことを表すのでそのまま残るのはよろしくない)
■ 乱入許可Watchは白く表示、乱入拒否はグレイ表示
　 旧verではどちらもbusy扱いとする。
■ 接続可能watchでもロード完了まではBusy(Casting)[灰]としておき、接続できない
■ busy状態＋watch可能かどうかを示すフラグが必要
　 相手と自分がwatch有効ならばwatch可能とする Busy(Casting)[白]
■ 突然切れた場合の対処
　 簡単にフレームスキップができるかどうかによる
■ エラー情報収集のためのデータの送受信
　 CPU情報
　 FCWの状態
　 LIFE, TENSION, ACT.FRAME, ACT.ID 
   cfgのオプション
   ggオプション

～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～

12/5
　・完全にリプを送信することを考えるとIdle時にも配信を行う必要がある
　　いままでm_connectやm_watchを条件に動作していた部分の見直しが必要
　　とりあえずタイムアウトの方法に問題がある

12/4
　・中継配信時にヘッダー部分しか遅れていなかった問題
　・ロード待ち画面の作成（未確認）
　・すべてデータ取得された場合はwatchinしない
　・再生が停止してからもいつまでもデータが送られてこない場合は切断
　・データが未完成のとき１秒間データの受信がない場合、定期的に再接続を行う

12/2
  ・リプレイの終端を定める
　　ffff=未取得
　　fffe=SYNC ERROR
    fffd=CONNECTION ERROR
　　090f=ソフトリセット
    それ以外は普通の入力

12/1
  ・対戦前にwatch状態にしておくと観戦側がクラッシュする
　・配信元が試合終了すると、観戦側のバッファが残っていても終了してしまう
　　リプレイデータだけでは対戦が終わったのかどうか知る方法がない
　・デバイスロストするとウインドウのサイズと表示域がおかしくなる

11/29
　デバッグ用に観戦中に親とルートと子の名前を表示する

11/28
　ノードの判別をIPと名前の一致とした
　
　同じ人が連続で対戦してたら区別が付かない
＞watchinに受信済サイズを送ることで判別可能

11/27
　同IPノードを識別したいので名前を追加しようと思っている
　もともと区別していなかったのでこの機会に対応しておく
　
　ついでにノードリストのテストもしておくか
　
　configに追加予定

　観戦中の配信と対戦中の配信は別の問題
　やはりmaxnodeは2~5くらいであるべき
　
　watching
　　enable broadcast[check]
    allow intrusion [check]
　　save replay     [check]
    max nodes (0~4) [combo]
　　
　＊datの仕様が変わるときバックアップする

　再生のマージンは回線事故（親の喪失など）を
　回避する目的がある。余白部分は高速再生させない

　ツリー階層の低いほど接続の優先度は低い
　watchinrepで階層を返し、最良のノードを受信対象とする
　受信対象ではないノードからのデータ送信は無視　
  邪魔なノードをどう切るか？

11/22 11/26
  【クライアント】
  watch状態の全ノードにwatchin要求を出す　何処からも応答が無い場合、配信元にwatchinする　そこにも空きがない場合watchは失敗する
  （ツリーが均等に配置されないが遅延が起きるだけなのでまあいいか）
  送信親のアドレスを固定しない、watchDataが来たアドレスに対してreplyを返すだけ（なので急に親が変わっても問題なし）
  一定時間watchDataが来ない場合（親が切断した場合等）、再度watch状態の全ノードにwatchin要求を出す
　このとき子供はそのまま引き連れていれば良い。
　格納先はreplayと同じでいいのか？
　replayの再生機能がそのまま使えるのなら使う価値はある！！
　
　【サーバー】
　観戦許可していても試合開始までは観戦を受け付けない
　
　自分の受信サイズー子の受信サイズ分を送り続ける（サイズが０でも送ることで存在している証明となる）
　watchDataReplyが返ってこない子は削除する
　
　watchinを受け、要求と自分の観戦対象が同じだった場合
　空きがあれば、子として登録する　watchinreplyに接続できたことを通知する
　空きがなければwatchinreplyに接続できないことを通知する
　【ルート】
　最大接続数をオプションで設置する
　リアルタイム配信なら子の空きが優先されるため意図的に制限することもないか
　最大接続数が許す限り直接接続を許可する
　（子を持てない未開放ポートは邪魔なのでルートに接続要求が来た時、子を持たないノードを切断するか？）
　観戦不可の場合galleryに×と表示される、有効なら観戦者数を表示
　
　・観戦者は両者のIPを知っている（相手はwatchinrepで教えてもらう）
　・観戦中はPingに応じる（Idle扱い）
　・バッファ分があれば高速再生可能
　・watchoutはいらない？
　・記録済リプはとりあえず保留とする
　　リスト表示も必要ないのでメニューから"play game"を置き換える形になる
　　保存事態はするので次の試合でリプ情報が書き潰される心配は要らない
　　ちゃんと目的のリプを追跡できるように
　　試合終了直後に退避したデータを見るようにしてもいい（今は残骸を見る形になっているはず）
　・総合観戦者数を表示したいwatchDataReplyで親に自分の子・孫の数を報告する
　　対戦者同士が定期的に子の数を送信しあって合計を算出する
　　どっちみち子にフィードバックしなくてはならないので、子からすべてのIdle/NotReadyノードに対して観戦者数を送信する

別件
　
　異様にブロック転送が遅い場合、パケットサイズが大きすぎてロストしまくっているのかも？
　サイズを縮小し、互換性も保たれるように！

　不完全なリプはincompleteとか付ける？

　Scoreを少数で表示

　強制frameskipがそれなりに意味がありそう
　
9/25
　[Send Message]
　　MessageBoxやOK,Cancel等の移動はTAB、Shift-TABキー
　　Ctrl+ZXCVはサポート
-------------------------------------------
　[Recent Message]
　　msg.txtに永久に保存される
　　起動時からの最新の１０件程度をリスト表示し、
　　メッセージを開ける。操作は受信時と同様。
　　但し、Close選択でメッセージリスト選択メニューに戻る。

　Lobbyを開いている時でメニュー開いてない時にメッセージが来たら
　NotReady状態となり、メッセージと差出人を表示する。
　Play/Watch、Reply、Closeがあり、Closeにデフォルト、Closeしてもメッセージ残ってたらそれを表示

8/30
・メッセージ機能仕様案
　　固定長256byte程度で十分
　　メニューに追加
      Send Message
      Open Message
    いつでも受信可能
    送信は１回のみで失敗したらSend Errorと表示
　
　ロビー以外でも簡易メッセージを送りたい
　　

・マシン識別コード生成
　・ユーザーにより変更不能
　・重複しない

7/19
・全体の送信サイズは45kb程度と思われる
　リプデータ本体から直接読み出しているため
　対戦終了時に破棄されてしまう。
・
　
7/13
・LobbyEnter時、削除せずに情報を再取得
・過去verで?rankがいる可能性があるのでその対策
・起動中設定変更をサポートする場合、pingrepliteに付加すべき情報を追加する必要あり！！
　今は一旦抜けて再接続するとつながるんじゃないか？
　相手がメニュー開いてるとそれが伝わるか？拒否状態が即座に伝わるか？

・iniファイルの読み書き
　今回はデータ送信をiniファイルに追加するのはやめておく。原因特定が難しくなりそうなので

・描画をオフにするとどれくらいの速度で再生できるか実験

・strncpyがやばかったので修正

7/12
?rankは強制初期化
勝手にnodelistをクリアしない。clear node listを実装し必要であればユーザが実行する

////////////////////////////////////////////////////////

【検討事項】
・NoResにPing打つメリット／デメリット
  ずっとNoResだったらノード削除する？
　Sort時にNoresをクリア？

・メッセージ未受信はそれとわかるようにする　Non Reception...

・処理落ち率の記録

・UDP開いてないとどうなる？

・通信内容をzlib圧縮したら早くなる？
　圧縮と展開に掛かる時間はどれくらい？

・自己申告でいいから低SpecPCとPort0は分かるようにする？

・ChatはやめてIMにする？

・ソフトリセット封印

・ディレイ違いでも接続可能にする
　FPSみて自動かつ動的にディレイ補正する機能も無いとあまり意味ない。
　かといってディレイの補正幅を決めないと逆にやりづらい？
　低スペックには無意味
　
・メッセージ機能について
　cfgにあらかじめ設定しておく
　Functioonキーに割り当てていつでも送信可能
　対戦中の相手からのメッセージは即座に表示
　ログにも残す
　メッセージ機能使用するかどうかのオプション必要

・観戦時は同期チェックバイトも送信する
　ずれたら切断し、末端のノードに代役を頼む
　多少のトラブルは遅延で吸収したい

【今後の予定】
□ESCでLeaveServerする
□ネット対戦中は本来のESCを無効にする？
□リプレイ鑑賞がダイアグラムに影響してしまう不具合
□ウインドウ／フルスクリーン切り替え
□ggxx上でnetオプション変更
□ポート変えるまでおかしな動きをするNoResponse
　ポート番号は相手に覚えられていて更新されていないのでは？
　VerErrとかでpingを無視している可能性もある
□同期ズレ対策
□処理落ち率で低スペック判定
　処理落ち率が１００％に近いと低スペックとみなして問題ない
△日付ごとリプをディレクトリに分けて保存する
△同一カラー回避（余裕があれば）
△リプレイUL,DL（擬似観戦）
△ggxxのプロセスが死なない？
　>>スレッドを確実に殺すようにしたので直ってるかも
△クラッシュする？
△ランダムセレクトをカーソル記憶
△リプのシーク機能（リアルタイム観戦に通ずる機能なので先に対応すべきか？）
×トレモリプレイ（需要なさそうなのでやめ）
×非ショートカットメニュー(技術的に挫折)
×主な使用伽羅表示（PRでカバー可能　対応中止）
×Start>Disconnectできたほうがいいか？（いらない）
×フレームスキップオプション（30FRAME機能が既にある）
×名前変更時にRANKなどを初期化

///////////////////////////////////////////////////////////////////

【メニュー化対応】
　「要求」
　　　・ノードに対する処理が多くなりメニュー呼び出し＞処理選択のステップを踏む必要あり
　　　　メニュー操作時はNOT READYとなっているべき
	・CONNECT / WATCH	(busyかどうかで切り替わる)
　　　　・
	・WATCH REPLAY
　　　　・DENY ON/OFF
　　　　・INFOMATION
	-------------------
	・CONFIG
	・

///////////////////////////////////////////////////////////////////

【観戦機能】
　「要求」
　　　・特定のノードについて参照可能にする
　　　・DL要求してすぐに見たい（IDLE待ちはしたくない）

　「対応方法」
　　　・観戦者間でツリーを形成する。
　　　　縦長になると遅延が起こりやすく、
　　　　横長になるとノードの負荷が高くなる。

　　　・当然ながら観戦者に対して同期は行わない
　　　　観戦者への配信はディレイ多めで大量のマージンを持たせる
　　　　取りこぼしなどがあり、観戦者側で入力が得られない場合、
　　　　観戦者のtimeをリセットする要求を出し、補正する。
　　　　time差が一定以上になったらキーデータが送信される。
　　　　毎フレーム送る必要は無い。基本的に観戦はDelay6で送受信する予定なので
　　　　6Fに１回くらいの頻度で十分だと思う。

　　　・配信者が途中で中断した場合、その旨表示したい（観戦側の問題か見分けが付かなくなるため）
　　　
　　　・観戦参加する場合、全WATCHノードを検索し、目的の試合を既に観戦しているノードがいるか調べる
　　　　ツリーの上のほうから余裕のあるノードを検索し、開いていたらそこに子として登録させる
　　　　まず親ノードからリプデータをまとめて受信しする。受け取れたとこまでtimeを設定し、後は定期的に受信する。

　　　・観戦中止した場合、親と子を接続させる必要がある。
　　　　ツリーの末端の子を探してきてそれを自分の代わりとする
　　　　代わりとして紹介する前に自分の読み込み済みデータを全てコピーしておく。
　　　　そうしないと中断者が１次観戦者だった場合に配信者に負荷がかかってしまうかもしれない
	
　　　・データ自体は配信者とほぼ同じ分だけ読み込むが、
　　　　観戦者が再生するポイントはそれよりわずかに遅らせるべき？
　　　　観戦者はツリーの再構築などでデータ転送が停滞する恐れがあり、
　　　　回復するだけの時間稼ぎが欲しい。
　　　　
　　　・配信者はノードアドレス文字列を比較して小さいほうとする。
　　　　特に理由は無いが、回線の苦しいほうを判断する方法も無い。

　　　・観戦送受信はPCスペックがボトルネックにはならないし、
　　　　十分にディレイを設けてあれば回線速度がネックにもなりにくいはず。
　　　　なのでノード品質によってツリーを再構築する処理は必要ないかもしれない

　　　・観戦者数を表示したい

　「調査・情報」
　　　・busy中にkey以外の送信を行ったとして、通信の影響はどの程度か？
　　　　影響がそれほど無いようなら案２で確定なのだが…
　　　・ユニキャストを複数行うより、マルチキャストを行ったほうがネットワーク付加が少ない
　　　・観戦者には再送などの余計なことはしたくないので対戦者と観戦者に送る情報が同じとは限らない（マルチキャストは使えない？）
　　　・リアルタイムと過去のリプを混同できない
　　　・リアルタイムの場合、途中から再生できるようにすべきか？
　　　　配信者は記録途中のリプデータを送り、毎フレーム

　「案１」connection終了時に1P側がサーバーにうｐする
　　＠メリット
　　　・ノードに付加が掛からない
　　　・見たい時にいつでも見れる

　　＠デメリット
　　　・ユーザ数によってはかなりサーバーの容量を消費する
　　　　そのため古いリプをいつまでも保持しておけない
　　　・サーバーに負荷が掛かる

　「案２」P2P方式（常時）
　　＠メリット
　　　・サーバーに負荷が掛からない
　　　・見たい時にいつでも見れる

　　＠デメリット
　　　・ノードに付加が掛かる（１ファイル10kbと仮定すると20パケット程度）

　「案３」P2P方式（BUSY以外）
　　＠メリット
　　　・サーバーに負荷が掛からない
　　　・ノードに付加が掛かりにくい

　　＠デメリット
　　　・ノードに付加が掛かる（BUSY中は避けるので問題なし）
　　　・IDLE時を見計らって落とす必要がある

///////////////////////////////////////////////////////////////////

【ウインドウ／フルスクリーン切り替え】
　「手順」
　　１、Alt+Enterで関数コール

　　２、フォントはReset()で破棄されるらしいが、使っているのか？

　　３、IDirect3DDevice8::Reset()にD3DPRESENT_PARAMETERSを渡す
　　　　CreateDeviceに渡したものをそのままわたせばOK

	// sample
	HRESULT hr = m_D3DDevice->Reset(theApp.m_setting.m_fullScreen ? &m_D3DPP_Full : &m_D3DPP_Wnd);
	if (FAILED(hr))
	{
		if (hr == D3DERR_DEVICELOST)	// D3DERR_DEVICELOST==2152
		{
			m_deviceLost = true;
			return false;
		}
		APPERR("Failed to switch screen mode.");
	}

　　４、SetRenderStateなどを再度初期化する

　　５、フォントなどが必要なら作成

　　６、ウインドウモードにしたら↓で位置調整
　　　　SetWindowPos(m_mainWnd, HWND_NOTOPMOST,		// HWND_NOTOPMOST = -2
	m_mainWndLeftTop.x, m_mainWndLeftTop.y,		// 
	WINDOW_SIZE_X, WINDOW_SIZE_Y, SWP_SHOWWINDOW);	// SWP_SHOWWINDOW = 0x0040

///////////////////////////////////////////////////////////

109-4の時点で受信毎に3ms以上の遅延がある。
1F当たり５回のPingがあるだけで15msの遅延がある。
pingも混雑していると3msずつ遅れていくが

対策
①readserverを行わない(vsnetに入った時もいらない？)
②nores対策
③Sleep時間下げてスレッドの優先度を下げる


・Ping受信できるがPingRep受信できない場合、Port0かもしれない。
　（Port0の症状を確認すべき！！）
　もしそうならport0にはping送らない。

・Server違いをPingを無視することで対処するのもあまり良くない
　NoResを一定時間でクリアするようにするか、
　別のStateとすることでPingの送信をやめさせる必要がある
　
　対策１）一定回数連続でPingTimeoutしたらLost状態としてPingを送らない
　　　　　ノードリストには残っているので接続要求は受けられる
　
NoResの存在が通信障害になっている
NoResの理由として以下が考えられる

①PingがTimeoutしている
②ServerAddressが異なる
③port0
④退室している
⑤ノード取得したばかりで状態不明 UNKNOWN

NoResが大量にあるとbusy中にpingを送られ通信に支障が出る
①～④のping送信をやめ、⑤のみに遅れるようにしたい
少なくともbusyであることが伝われば対戦中の影響は抑えられる