Original Post : Second Life Wiki > LSL http server
始めに
これは llHTTPRequest と対になるものです。 llHTTPRequest はSecond Life内のスクリプトでHTTP-accessibleなソースからデータを要求できるものですが、このHTTP-in では外部ソールから Second Life内のスクリプトへデータを要求できます。大きな違いは llHTTPRequest がSL内のスクリプトが必要なときにデータを交換します。しかしHTTP-in ではSL内のスクリプトへ向けて、外部ソースが必要と判断したときにコミュニケートができます。
HTTP-in の重要なことは、 llHTTPRequest、llEmail、XML-RPCではポーリング（※一定時間単位で繰り返すこと）をすることで可能だった機能と同等の機能を提供することです。これらすべて扱いにくく、また、後者２つは拡張性が深刻なボトルネックとなっています。 LSL HTTPサーバではHTMLを扱わないということに注意してください。詳細は下記「その他の制限」を参照してください。
利用
- 手軽にLSLスクリプトからビューア外部、スクリプト、サーバからデータを取得できる
- ビジター･カウンタや各種統計といったWebフロント・エンドなど
- 手軽にLSLスクリプトでビューア外部、スクリプト、サーバからデータを取得できる
- L$やIntentoryアイテムを取引するin-worldオブジェクトとコミュニケーションするWebフロント･エンドを持つ店舗
- 外部アイテムを操作する必要があるために外部プログラムでメインロジックが必要なin-worldゲーム
簡単な技術情報は下記をごらんください。または Script Examples をどうぞ。
スクリプトAPI
新規に LSL Server public URL を要求します。
要求に成功/失敗した場合、関数から返される key 値を含む http_request イベントが呼び出されます。
request_id = llRequestURL();
llRequestURL と似ていますが、HTTPS / SSL URL を要求します。
要求に成功/失敗した場合、関数から返される key 値を含む http_request イベントが呼び出されます。
セキュアURL、非セキュアURLにかかわらず、指定したURLを開放します。
llReleaseURL("http://sim3015.aditi.lindenlab.com:12046/cap/3ff4f3f2-ea08-76c1-cef6-a22b4a573a7c");
URLがたたかれたときに呼び出されるイベントです
- id はリクエスト毎にユニークです
- サポートするメソッドは GET/POST/PUT/DELETE です
- body： リクエストのbody
llRequestURL と llRequestSecureURL の応答としても呼び出されます
- id は llRequestURL または llRequestSecureURL で返される key値 と一致します
- method == URL_REQUEST_GRANTED がURLの取得に成功、URL_REQUEST_DENIED が失敗した場合セットされます
- body は public URL です。もし public URL の取得に失敗した場合は空になります
ステータス･コード status と body を送信します
- id は http_request イベントを呼び出したリクエストの id です
- 応答を送信するとリクエスタは、要求を開放し関連する情報を削除します
（※id で）指定されたリクエストの指定されたヘッダ情報を返します
- サポートされるヘッダは
- "x-script-url": ベースURL。llRequestURLまたはllRequestSecureURL から取得したものと同じ
- "x-path-info": 要求された url 以下に続くパス情報
- "x-query-string": url に続く ? 移行のクエリ･パラメータ
- "x-remote-ip": リクエストを行ったホストの IPアドレス
- "user-agent": リクエスタが付加するユーザ･エージェントのヘッダ
要求 url: https://sim3015.aditi.lindenlab.com:12043/cap/a7717681-2c04-e4ac-35e3-1f01c9861322/foo/bar?arg=gra
x-script-url: https://sim3015.aditi.lindenlab.com:12043/cap/a7717681-2c04-e4ac-35e3-1f01c9861322
x-path-info: /foo/bar
x-query-string: arg=gra
このヘッダ情報は３０秒間、または llHTTPResponse が使用されるまで有効です。
URLの有効期間に関する制限
- URL は一時的なものです！
- URL は下記に挙げる状況が発生した場合、失われます。該当するイベントを併記します。
- オブジェクトの derez/rez： on_rez
- スクリプトの保存/リセット： default state の state_entry() (複数 state を持つスクリプトは注意)
- リージョン移動、またはTP（アタッチメント）： changed() イベント の CHANGED_REGION と CHANGED_TELEPORT フラグ
- リージョンの再起動： changed() イベント の 新規 CHANGED_REGION_START フラグ
- URLが"失われた"場合、つまりスクリプトに割り当てられた public url がすべて失われると、新しいURLを取得する必要がありますが、新しいURLは以前のURLとは異なります。
- 継続するURLを整備するには Dynamic DNS サービスがどのようにしてドメイン名とIPアドレスを動的に結びつけるのかに似た外部サービスの構築・使用が必要となるでしょう。
Goggle App Engin で利用されている Dynamic DNS サービスが例として寄稿されたフォーラムはこちら： http://forums.secondlife.com/showthread.php?t=323981 - HTTP-Server用 static URLを提供するAPI（開発中）はこちらをどうぞ。（提供：SLTools）
リソースに関する制限
- リージョンごとに、土地所有者に対するプリム数制限と同じ数だけ、使用可能なURL数が制限があります
- llGetFreeURLs を使用することでスクリプトで利用できる正確なURL数が取得できます
- 使用できるURLの数は、parcelに置かれるプリム数制限と同じです
- オブジェクト所有者にかかわらず、parcel 上のオブジェクトは parcel に割り当てられたリソースを使用します
- プリムと同様、同一リージョンで同一所有者をもつ複数 parcel はリソースを共有します
- Iもし１リージョンに各１００ url をサポートする parcel を２つ所有しているならば、ひとつの parcel 上で合計２００ url を利用できます
- リージョンの object bonus factor は利用可能 URL 数に影響を与えません
- 2x bonus factor を持つリージョンで最大３００プリムを許可されていても、１５０ url のみ利用できます
- Residents 一人あたり、固有に最大３８のURL数がリソースとして利用可能です
- １アタッチメントあたり１ URL として計算されていますが、３８ URL全部を１アタッチメントで使用することも可能です
- Vehicle については以下の条件で、特別かつゆるく Resident リソースに移動します
- Resident が sit したオブジェクトをすべて 'vehicle' とします
- Vehicle は parcel 境界をまたぐまでは rul を parcel リソースから消費します
- 誰かが sit することで 'Vehicle' 扱いになった場合にベンダ・マシンなどが誤動作しないようにするための、特別な予防策です
- Resident が sit しているURLリソースを使用するオブジェクトが parcel 境界をまたいだ場合、sit した順番で、かつ、十分なリソースを持つ resident のリソースを使用します。もし sit しているアバターに十分なリソースがない場合、移動先の parcel のリソースが使用されます。もし それでも十分なリソースがない場合、vehicle の移動はブロックされます
- つまり、vehicle については常にホストされるリソースの割当先を探しますが、それができない場合は移動がブロックされます
- Parcel の販売： （売り手または買い手の）Residents のどちらかにリージョン内での許可URL数が変更されるような parcel 売買が発生した場合、許可される以上に使用されているURLを含むオブジェクトはリターンされます。
- リターンされるオブジェクトは、URLを使用しているオブジェクトのうち、カテゴリ－Temporary、Other、Group、Owner、Selected/Sat upon－順、若いオブジェクト順にリターンされていきます。
- オブジェクトがリターンされるのは parcel の所有者が変更された時のみで、許可されたリソース以上を使用している場合に限ります
- リターンは、若い Temporay オブジェクト、古い Temporay オブジェクト、若い 'Other"（グループ所有でも、parcel 所有者の所有でもない）オブジェクト…の順に行われます
その他の制限
- リクエストのbodyサイズは２Kバイトに制限されます
- リクエスト･ヘッダのサイズは２５５バイトに制限されます。このサイズは各ヘッダ毎であり、総量ではありません。
- リクエストへの応答のサイズには今のところ制限はありませんが、試験期間中に検討されている項目です
- 返されるcontent typeは常に'text/plain; utf-8' です
- 将来的にはその他の content type に対応する可能性はありますが、約束はされていません
- １スクリプトで扱える待機リクエストは最大６４です。これはLSLの待ちイベントの最大数に基づきます
- サーバレベルによるCAPに基づいてhit数を抑制するかもしれません。これは可能ですが、まだ行われていません。
- プレーン・テキストでのみ出力されますので、外部パーサーなしでHTMLとして扱えません。パーサーを作成するのであれば、帯域を消費されないようにLinden LabからのURL限定でアクセスできるようにすべきでしょう。
リンク
|