![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
情報サーバ(sl_info)は，起動すると最初に情報収集サーバと呼ばれるプロセスを１個だけforkします．これは sl_cacheのキャッシュPUTサーバと同じ考え方です．
情報収集サーバはキャッシュPUTサーバと同様にSIMの情報をDBへ保存します．情報収集サーバにSIMの情報を集約しするのは２つの理由からです．
DBに保存されるSIMのデータは
送られて来るSIMの情報は，現在のところ，Viewer(アバター)がハンドシェイクしたSIMの情報のみです．従って，ホワイトフィルタの制限がかかっている状態のアバターからは新しいSIMの情報が送られてくることはありません．
なぜならば，ホワイトリストの制限がかかっている状態とは，以下のような状態のことだからです．
新しいSIMの情報を集める場合は，ホワイトリストの制限のかかっていないアバターを使用しなけばなりません．なお，sl_relayでの収集自体は特別な操作を行うことはありません．訪れたことのないSIMの辺りをアバターが飛び回っているだけで，自動的に情報が情報収集サーバに送られます．
情報収集サーバはSIM情報の他に，sl_relayを利用しているユーザ（アバター）の情報も収集します（ただしDBには保存されません）．
収集するアバター情報は以下の通りです．
「アバターが現在いるSIMの名前」については，データベース上にそのSIMのデータがないと情報を得ることはできません．
sl_info を -l オプションで起動した場合，収集したアバタの情報は指定されたログファイルに保存されます．
デフォルトは /var/sl_proxy/sl_info_agent.log です．
リレーサーバ(sl_relay) は -is のオプション付で起動された場合，Secod Lifeへのログイン処理の途中で情報サーバ(sl_info)に接続をしてきます．sl_relayから接続を受けた情報サーバはコントロール用プロセスをforkします．forkされたコントロール用プロセスはsl_relayとネゴシエーションを行い，それぞれの使用ポート番号や接続用のパスワードを交換します．
従って情報サーバのコントロールプロセスはsl_relayを利用するアバター毎に起動されます．
情報サーバのコントロールプロセスはその後，情報収集サーバへ情報を転送する中継プロセスを forkします．このプロセスは sl_relayからのアバターとSIMの情報データを受信し，情報収集サーバへそのまま転送します．
コントロールプロセスはその後ループに入り，情報提供サーバとして，(UDP/HTTPS)中継コントローラーからのリクエストを待ちます．
情報サーバのコントロールプロセスは，情報収集サーバへ情報を転送する中継プロセスをforkした後，情報提供サーバとして作動します．
情報提供サーバは以下の情報を提供することができます．現バージョンのsl_relayでは専らホワイトリストの検索に使用します．
リレーサーバ(sl_relay) は -is のオプション付で起動された場合，Secod Lifeへのログイン処理の途中で情報サーバ(sl_cache)にTCP接続を行います．その後 fork情報サーバのコントロールプロセスとネゴシエーションを行い，それぞれの使用ポート番号や接続用のパスワードを交換します．
sl_relayはログイン処理中にアバターの情報を収集し，情報収集サーバへの中継プロセスに情報を送信します．
sl_relayでは，各中継プロセスが得たSIM及びアバターに関する情報を一旦中継コントローラに集め，中継コントローラがまとめて情報収集サーバへの中継プロセスへデータを転送します．
現バージョンでは，sl_relayは sl_info のWhite Listの検索機能しか使用していません．
ホワイトリストに関する連携については sl_infoの ホワイトリストフィルター を参照してください．
