#author("2025-04-15T09:59:10+00:00","default:iseki","iseki") #author("2025-04-15T09:59:25+00:00","default:iseki","iseki") ** [[sl_info]] 連携 [#oa9e9b4a] *** 情報サーバとのネゴシエーション [#af9486ca] リレーサーバ([[sl_relay]]) は ''-is'' のオプション付で起動された場合,[[Second Life]]へのログイン処理の途中で情報サーバ([[sl_info]])にTCP接続を行います.その後情報サーバのコントロールプロセスとネゴシエーションを行い,それぞれの使用ポート番号や接続用のパスワードを交換します.~ また,[[sl_relay]]はログイン処理中にアバターの情報を収集し,情報収集サーバへの中継プロセスに情報を送信します. *** 情報収集サーバへのデータ転送 [#b0c7290c] [[sl_relay]] では,Relay Server の各中継プロセスが得たSIM及びアバターに関する情報を一旦中継コントローラに集め,中継コントローラがまとめて情報収集サーバへの中継プロセスへデータを転送します. *** 情報提供サーバ [#p5f9f1d6] 現バージョン(1.5.1)では,[[sl_relay]]は [[sl_info]] のWhite List の検索機能しか使用していません. *** ホワイトリストによるフィルタリング [#ede636c8] [[sl_relay]] は ''-wf'' オプションが指定された場合,ホワイトリストによる制限モードとなります.なお ''-wf'' が指定された場合は,自動的に ''-is'' も指定されたことになります.~ 制限モード下では,UDP中継プロセスは新しいSIMサーバの接続要求パケットを受信すると,そのSIMがホワイトリストに載っているかどうかを中継コントローラを通して [[sl_info]] に問い合わせます.もしホワイトリストに載っているのなら,そのSIM用のUDP中継プロセスを起動し,載っていない,若しくは不明の(データベースにSIMのデータがない)場合は,そのまま接続要求パケットを破棄します.~ 現バージョン(1.5.1)ではこの動作を行うのは,UDP中継プロセスだけであり,HTTPS中継プロセスはこのような動作は行いません.~ UDP中継プロセスが接続要求パケットを破棄する行為は ViewerやSIMサーバから見ると,パケットロスを起こしたように見えます.このためSIMサーバは,このパケットの再送を繰り返します.~ これらの再送パケットに対しても,その都度 [[sl_info]]に問い合わせたのでは効率が悪いため,コントローラは以前問い合わせた結果をキャッシュとして保持しています. *** WEBプロキシを使用する場合の注意点 [#o20276f8] [[sl_info]] でのホワイトリスト機能では,ユーザ(アバター)単位やViewerの作動するマシン単位でホワイトリストを記述することができます.~ 一方,ViewerがWEBプロキシの設定を行った場合,[[sl_relay]]から見ると,途中でIPアドレスが変化したように見えます([[WEBプロキシ機能>../WEBプロキシ機能]] 参照).もしこの時,情報提供サーバ側で該当マシンに対して,マシン単位のホワイトリストの記述が行われているとすると,情報提供サーバは正確な判定を行うことが出来なくなります.~ 一方,ViewerがWEBプロキシの設定を行った場合,[[sl_relay]]から見ると,途中でIPアドレスが変化したように見えます([[Webプロキシ機能>../Webプロキシ機能]] 参照).もしこの時,情報提供サーバ側で該当マシンに対して,マシン単位のホワイトリストの記述が行われているとすると,情報提供サーバは正確な判定を行うことが出来なくなります.~ これを避けるため,このような場合 UDP中継プロセスは,情報収集サーバへ送った情報とは別に,情報提供サーバへもViewerのIPアドレスが変化したことを通知します.この通知を受け取った情報提供サーバは現在のホワイトリストを破棄して,新しいIPアドレスのホワイトリストを読み込みます. どちらにせよ,複雑な処理になることが十分予想されるので,ViewerがWEBプロキシ機能を使用している場合は,そのマシンやWEBプロキシに対してマシン単位のホワイトリストを記述することは避けるべきでしょう.