ADOBE®   MEDIA SERVER 5.0.3

デベロッパーズガイド

	翻訳：株式会社サムライズ

注意

Adobe Media Server® バージョン 5についての本ドキュメントは第三者によって翻訳されたものであり、Adobe Systems Incorporated（アドビ システムズ社）は本翻訳物の正確性や完全性を査閲していません。

サーバー間のピア紹介の配信

Flash Media Server 4.5

紹介を配信するワークフロー

注意：紹介を配信できるのはオリジンサーバー間のみです。エッジサーバー間では紹介を配信できません。また、 Authorization プラグインを使用して紹介を配信することはできません。

Adobe Media Server は、RTMFP クライアントを互いに紹介し、クライアントが互いに直接接続できるようにします。この直接接続は、ピアツーピア接続と呼ばれます。この役割を果たす場合、Adobe Media Server は紹介者と呼ばれます。Flash Media Server 4.0 は、クライアントが 1 台のサーバーに接続している場合にのみ、クライアントを互いに紹介することができます。クライアントが個別のサーバーに接続されている場合でも、Flash Media Server 4.5 に追加されているサーバーサイド ActionScript API を使用して、クライアントを互いに紹介します。サーバー間に紹介を配信すると、ピアアシストネットワーキングアプリケーションの規模を調整することができます。

次の手順は、ピア紹介を配信するワークフローを示しています。

1   ピア参照イベントをサーバーサイドスクリプトエンジンにディスパッチするようにサーバーを設定します。「イベントをスクリプトエンジンにディスパッチするサーバー設定」を参照してください。

2   紹介者として機能する堅牢なサーバーのグループを作成するサーバーサイドスクリプトを記述します。「堅牢なサーバーのみのグループへのサーバーのデプロイメント」を参照してください。

3   サーバー間にピア紹介を配信するサーバーサイドスクリプトを記述します。「配信された紹介の API」を参照してください。

ピア紹介が機能する方法

注意：ポートおよび IP の設定と NAT トラバースについての詳細は、「ピアアシストネットワーキングのポートと IP アドレスの設定」を参照してください。

1 台のサーバーでのピア紹介フロー

デフォルトでは、サーバーは、クライアントが同じサーバーに接続している場合に、クライアントを互いに紹介します。

1 つの RTMFP 紹介者に接続されているクライアントの紹介フロー。

クライアント 1 とクライアント 2 は、ローカルの NAT ／ファイアウォールを介して同一の Adobe Media Server に対する接続を確立しています。クライアント 1 は、手動または自動のピア検出のいずれかによってクライアント 2 を検出しています。クライアント 1 はクライアント 2 と直接接続することを望んでいます。次の手順は、紹介フローを示しています。

1 クライアント 1は紹介者（Adobe Media Server）にピア参照要求を送信します。ピア参照要求には、クライアント 2の NetConnection.nearIDが含まれています。nearIDは、クライアントとクライアントの紹介者へのアクティブな接続においてグローバルに一意のフィンガープリントです。

2   紹介者は次の処理を実行します。

a    クライアント2 の IP アドレスを含むリダイレクトメッセージでクライアント 1 に応答します。

b   クライアント 2 に転送メッセージを送信します。このメッセージでは、クライアント 1が接続を望んでいることをクライアント 2 に伝えます。

3     クライアントは次の処理を実行します。

a   クライアント 1 は、リダイレクトメッセージで受信したアドレスにピア参照要求を再送します。

b   クライアント 2 はクライアント 1 のアドレスに応答 Hello メッセージを送信します。紹介者が共通なので、クライアントは NAT ／ファイアウォールの内側であっても直接接続を確立します。

複数のサーバーでのピア紹介アプリケーションフロー

サーバーサイド ActionScript を使用して、複数のAdobe Media Server 紹介者にクライアント紹介を配信します。

異なる RTMFP 紹介者に接続されているクライアントの紹介フロー。

このシナリオでは、クライアント 1はサーバー Aに、クライアント 2はサーバー Bに接続しています。クライアント 1はクライアント 2のピア ID を認識しており、直接の接続を確立することを望んでいます。しかし、クライアント 2 はクライアント 1 と同じ紹介者には接続していません。サーバーがこれらのクライアントを互いに紹介できるようにするには、サーバーサイド ActionScriptを使用します。次の手順は、紹介フローを示しています。

1   クライアント 1 は紹介者 1 にピア参照要求を送信します。

ピア参照要求は、サーバーサイドスクリプトの application.onPeerLookup() イベントを呼び出します。ピアは、クライアント 1 の IP アドレス、クライアント 2 のピア ID、要求を特定するタグ、要求を受信した RTMFP インターフェイスの ID のすべてを渡します。

2     application.onPeerLookup()コールバックで、紹介者 1は、application.sendPeerRedirect()を呼び出し、リダイレクトメッセージでクライアント 1 に応答します。リダイレクトメッセージには、クライアント 2 の既知のアドレスと、紹介者 2 のパブリックアドレスが含まれています。

注意：クライアントにピア接続を確立させないようにする場合、紹介者 1はピア参照要求に応答しません。「紹介要求のフィルター処理」を参照してください。

3   クライアント 1 は、紹介者 2のアドレスにピア参照要求を再送します。

4   紹介者 2 は、ピア参照要求を処理するために次の処理を実行します。

a    クライアント2 の IP アドレスを含むリダイレクトメッセージでクライアント 1 に応答します。

b    クライアント 2 に、クライアント 1が接続を望んでいることを伝える転送メッセージを送信します。

5   クライアントは次の処理を実行します。

a   クライント 1 は、クライアント 2 が紹介者 2から受信したアドレスにピア参照要求を再送します。

b   サーバースクリプトは、クライアント 2 オブジェクトの Client.introducePeer() を呼び出し、クライアント 1 のアドレスに応答 Hello メッセージを送信します。

イベントをスクリプトエンジンにディスパッチするサーバー設定

デフォルトでは、サーバーはピア参照イベントを内部で処理します。複数のサーバーに紹介を配信するスクリプトを記述する場合、スクリプトエンジンにピア参照イベントをディスパッチするようにサーバーを設定します。Application.xml ファイルで、PeerLookupEvents の mode 属性を "All" に設定します。

デフォルトでは、サーバーは、グループに参加するピアとグループから退出するピアを内部で処理します。サーバーチャネルを使用してピアをグループ内にブートストラップするスクリプトを記述する場合は、サーバーを設定します。 JoinLeaveEventsの mode属性を "All"に設定し、これらのイベントをスクリプトエンジンにディスパッチします。

<Application>

...

<RTMFP>

<PeerLookupEvents mode="All"/>

<GroupControl>

<JoinLeaveEvents mode="All"/>

</GroupControl>

</RTMFP>

...

</Application>

mode属性に指定できる値は次のとおりです。

堅牢なサーバーのみのグループへのサーバーのデプロイメント

配信された RTMFP紹介者として機能するようにサーバーをデプロイするには、次の方法を使用してください。

•    サーバーレス RTMFP NetConnection と NetGroup を使用して、サーバーのみのグループに参加させます（この場合、groupspec はプライベートであり、クライアントと共有されません）。

•   永続的なグループメンバーを既知のアドレスに追加します。

•   サーバーチャネルを使用して、ピアブートストラップをグループ内のサーバーに配信します。

サーバーレスRTMFP NetConnection を使用したNetGroup の作成

紹介を配信する場合、サーバーは状態を共有している必要があります。すべてのサーバーはお互いを認識している必要があり、さらに、接続されたクライアントすべてのピア ID と near および far IP アドレスを認識している必要があります。状態を共有する最も簡単な方法は、NetGroup（グループとも呼ばれます）内のサーバーを接続することです。

紹介を配信する場合、サーバーグループは堅牢である必要があります。NetGroup内のサーバーが接続された場合、紹介者が失敗すると、その紹介者に接続されたすべてのピアが失敗します。堅牢なグループを作成するには、サーバーレスモードを使用して、サーバー間で RTMFP NetConnectionを作成します。サーバーレスモードでは、ピアサーバーのいずれかが失敗すると、他のサーバーは互いに接続されたままになり、グループを脱退する失敗したサーバーが通知されます。

サーバー間でサーバーレス接続を使用し、サーバーサイド「ピア」の接続が維持されて、ピアIDが変更されないようにします。グループは、GroupSpecifier.ipMemberUpdatesEnabledを使用して、同じサブネット上のネイバーを見つけることができます。

次のコードでは、接続がサーバーレスモードで作成されます。

var nc:NetConnection = new NetConnection;

nc.connect("rtmfp:");

サーバーのみのグループへの永続的なメンバーの追加

この手法により、異なるサブネット間のピアのグループを結合します。永続的なグループメンバーとして機能するサーバーを選択します。例えば、各サブネット上の 1 台のサーバーまたは各データセンターの 1 台のサーバーの既知のアドレスを特定することができます。設定ファイルを使用して、既知のアドレスを他のサーバーに配信します。既知のアドレスのサーバーはグループのメンバーであり、この既知のアドレスを介してサーバーに接続する他のノードとのピアツーピア接続を開きます。接続されると、この「ブートストラップノード」は、そのネイバーにグループ内の他のピアを通知します。グループ内のビルトイン対話機能は、変化する接続を利用するサーバーのみのグループを作成します。

赤色サーバーはサーバーのみグループのブートストラップノードです

上の図で、赤色サーバーはブートストラップノードです。実線は永続的なメンバーへの接続です。点線は、グループの自動対話機能を使用して作成されたピア接続です。

次のサーバーサイド ActionScript API を使用して、永続的なメンバーをサーバーのみのグループに追加します。

•     NetConnection.rtmfpBindAddresses

NetConnection が、その RTMFP プロトコルスタックを開くときにローカルにバインドする特定のアドレスを表す文字列の配列。

•     NetConnection.rtmfpEndpointName

ローカル RTMFPプロトコルスタックのエンドポイント名。

•     NetGroup.addPermanentNeighborByName()

ピア IDの代わりに、RTMFPエンドポイント名を使用して、ネイバーを手動で追加します。ピアがこのネイバーから切断された場合、ピアは自動的に再接続を試みます。

•     NetGroup.removePermanentNeighborByName()

RTMFPエンドポイント名により、ネイバーの「永続的」ステータスを手動で削除します。このメソッドを呼び出しても、接続は切断しません。ただし、将来どちらかの側が接続の切断を選択した場合、切断が可能です。

次の図は、サーバーのみのグループのブートストラップを実行するアプリケーションフローを示しています。

注意：太字の呼び出しは、新しいサーバーサイド ActionScript API です。

クライアント 1 がクライアント 2 との対話を開始しますが、そのピア ID を認識していないので、このタイプのブートストラップは固有のものです。クライアント1 は、IP アドレスと rtmfpEndpointName のみを認識しています。

クライアント1 が addPermanentNeighborByName() を呼び出し、クライアント 2 の rtmfpEndpointName を渡すと、クライアント 2 は、クライアント 1 のピア ID を取得します。クライアント 2 は、そのピア ID を使用して、クライアント 1 を逆方向のネイバーとして追加します。

これらの 2つのピアがネイバーになると、両方のピアがサーバーサイド ActionScriptの NetGroup.Neighbor.Connectイベントを受信します。これらのピアの各 RTMFPスタックは、他のピアについてお互いに対話し、最終的に接続されたグループを生成します。

イニシエーターが適切な groupspec値を使用してネイバーを追加するので、セキュリティリスクはありません。この値を安全に配信して、推測できないようにすることができます。クライアント 1が groupspecを認識しない場合、サーバーは、クライアント2 を永続的なネイバーとして追加する要求を無視します。

NetGroup.addNeighbor()  や  NetGroup.addMemberHint()  とは異なり、NetGroup.addPermanentNeighbor()  メソッドでは、このネイバーが削除された場合に、ローカル RTMFPスタックがこのネイバーを自動的に追加します。永続的なネイバーは、グループが、個別のサブネットにメンバーノードを持つグループ間の完全なつながりを維持できるようにします。

ローカルノードが接続されたグループのメンバーであるかどうかを決定するには、設定された間隔でブートストラップノードから NetGroup.post()を呼び出します。他のノードはこれらのメッセージをリッスンし、これらのノードがブートストラップノードを含むグループのスライスに接続されているかどうかを検出することができます。ノードがメッセージを受信しないときは、管理者に通知するか、またはシャットダウンする場合があります。

これらの API の詳細については、『サーバーサイド ActionScript リファレンスガイド』を参照してください。

サーバーチャネルを使用した、サーバー間のピアブートストラップの配信

サーバーサイドActionScript は、ピアをグループにブートストラップする次の方法を提供します。

•    GroupSpecifier.addBootstrapPeer(peerID)

ピアがグループに参加する前に、ピア IDをグループ指定子に追加します。

•    NetGroup.addNeighbor(peerID) および NetGroup.addMemberHint(peerID)

ピアをグループに手動で追加します。これらのメソッドは、ピア IDを配信する外部フレームワークを必要とします。

•    GroupSpecifier.ipMulticastMemberUpdatesEnabled

ピアが LAN上でお互いに認識できるようにします。

•   サーバーチャネルを使用します。

このメソッドでは、LANが不要で、ピア IDの知識は必要ありません。

次の APIを使用し、サーバーチャネルを経由してサーバーをグループにブートストラップします。

•    Client.onGroupJoin(groupcontrol)

ピアがグループに参加するときに呼び出されます。デフォルトでは、サーバーは参加および退出に関するイベントを内部で処理します。サーバーサイドスクリプトのこれらのイベントを処理するには、Application.xmlファイルを設定します。「イベントをスクリプトエンジンにディスパッチするサーバー設定」を参照してください。

•    Client.onGroupLeave(groupspecDigest)

ピアがグループを退出するときに呼び出されます。

•    GroupControl.addMemberHint(peerID)

その peerID がグループのメンバーであることを指定するレコードを手動で追加します。トポロジーに必要な場合にのみ、すぐにこのピアへの接続が試行されます。

•    GroupControl.addNeighbor(peerID)

既にグループに存在しているはずの指定された peerIDへ直ちに直接接続することによって、手動でネイバーを追加します。

•    GroupControl.groupspecDigest

正規の groupspec のダイジェスト。クライアントが参加したグループを安全に識別します。

GroupControlオブジェクトを使用して、ネイバーを追加するようにピアに通知します。アプリケーションコードで、onGroupJoin()および onGroupLeave()イベントを受信したときにグループ名とグループ内のピアのテーブルを維持します。新しいピアをネイバーとして追加するように伝えるメッセージをグループ内のピアに送信します。

GroupSpecifier.serverChannelEnabled フラグが true に設定された状態でクライアントがグループに参加すると、Client.onGroupJoin() コールバックイベントがサーバーサイド ActionScript に送信されます。このメソッドのパラメーターは、グループの正規の GroupSpecifier 文字列のダイジェクトを含んだ GroupControl オブジェクトです。スクリプトで、この groupspecDigest 文字列は、接続されたクライアントとグループのメンバーであることを示す GroupControl オブジェクトのリストを格納するテーブルのキーとして使用できます。あるクライアントがグループに参加すると、同じグループに参加している他の接続されたクライアントをこのテーブル内で検索します。検索に成功した場合、 groupControl.addNeighbor() または groupControl.addMemberHint() メソッドを呼び出し、新しいクライアントをピア接続でグループ内の他のネイバーにブートストラップします。

グループに参加した特定の NetGroup オブジェクトへの groupspecDigests のマッピングを維持するには、サーバーサイドの GroupSpecifier.encodeGroupspecDigest() メソッドを呼び出します。ソース GroupSpecifier がある場合、このメソッドは groupspecDigest を生成します。ソース GroupSpecifier がない場合、サーバーは GroupControl オブジェクトの groupspecDigest プロパティを不透明な文字列として扱う必要があります。ダイジェストから開始 groupspec 文字列の値に移動することはできません。

次のサーバーサイドスクリプトは、サーバーチャネルブートストラップ APIを使用します。

var groups = {};

Client.prototype.onGroupJoin = function(groupControl)

{

groupControl["client"] = this; // Remember the associated Client.

var groupControlArray = groups[groupControl.groupspecDigest];

if (groupControlArray)

{

trace("Register Client in existing Group (by groupspec digest): " + groupControl.groupspecDigest +

", current Group size is: " + groupControlArray.length);

// find a random member to bootstrap with r = Math.random();

index = Math.floor(r * groupControlArray.length);

var peerGroupControl = groupControlArray[index];

groupControl.addNeighbor(peerGroupControl["client"].farID);

groupControlArray.push(groupControl);

}

else

{

trace("Track client joining new Group (by groupspec digest): " + groupControl.groupspecDigest);

groupControlArray = [];

groupControlArray.push(groupControl);

groups[groupControl.groupspecDigest] = groupControlArray;

}

}

これらの API の詳細については、「サーバーサイド ActionScript リファレンスガイド」を参照してください。

配信された紹介の API

配信された紹介のサーバーサイド ActionScript API を使用して、ピア紹介プロセスを制御し、共有されたピアレジストリを作成してください。

ピア紹介プロセスの制御

•    Application.onPeerLookup()

クライアントがピア参照を開始するときに呼び出されます。このイベントは次のプロパティを持つオブジェクトを受け取ります。

•    Application.sendPeerRedirect()

application.onPeerLookup()   コールバック関数からこのメソッドを呼び出し、参照を開始するピアにターゲットピアのアドレスの配列を送信します。

•    Client.introducePeer()

接続要求を開始したピアとの接続を開くようにターゲットピアに要求します。

これらの API の詳細については、「サーバーサイド ActionScript リファレンスガイド」を参照してください。

ピアレジストリの作成

これらの APIを使用して、ピアレジストリを作成します。ピアレジストリには、紹介者に接続するすべてのクライアントのピア IDと IPアドレスが一覧表示されます。分散環境で紹介者として機能するすべてのサーバーは、このピアレジストリを共有し、ピア参照を受信すると、このレジストリを使用してピアを検出します。ピアレジストリを作成して共有するアプリケーションロジックを記述します。

•    Client.farAddress

サーバーがクライアント接続の作成元を参照するときに取得する IPアドレスとポート番号。

•    Client.nearAddress

クライアントが接続されているサーバーのパブリックアドレス。

•    Client.potentialNearAddresses

サーバーとの通信に使用可能なパブリックインターフェイス。

•    Client.reportedAddresses

クライアントが RTMFPトラフィックを受信できるアドレス。クライアントは、サーバーへの RTMFP接続の存続期間中に、この値を複数回更新することがあります。この値には、クライアントがその NATの内側で開いた IPアドレスとポートを含むことができます。その場合には、共通の NATの内側で他のピアと対話するためにこれらのアドレスとポートを使用します。

•    Client.onFarAddressChange()

クライアントの farAddressが変化したときに呼び出されます。例えば、LANからワイヤレス接続へのクライアントトランジションの際にアドレスが変化した場合などです。

•    Client.onReportedAddressChange()

クライアントが新しいアドレスを報告すると呼び出されます。

これらの API の詳細については、「サーバーサイド ActionScript リファレンスガイド」を参照してください。

例：サーバー間の紹介配信

これは、サーバー間に紹介を配信する方法の高いレベルの例です。

サーバーのグループに紹介を配信するには、すべてのサーバーが、接続されたすべてのクライアントのピア IDと IPアドレスを認識している必要があります。これらの値をピアレジストリで追跡します。次の例では、ピアレジストリを制御する次の関数があることを前提としています。

•    addClient(peerId, clientAddresses)

クライアントがサーバーに接続するときに、ピア IDおよびとアドレスをピアレジストリに追加します。

•    removeClient(peerId)

クライアントがサーバーから接続解除するときに、ピアレジストリから削除します。

•    updateClient(peerId,   clientAddresses)

報告されたアドレスの farアドレスが変更されたときに、ピアレジストリの報告されたアドレスを更新します。

•    getClientIfLocal(peerId)

指定された peerIdのクライアントが現在のサーバーに接続されている場合は Clientオブジェクトを返します。それ以外の場合は nullを返します。

•    getRemoteClientAddrs(peerId)

指定されたピア IDのピアレジストリからクライアントアドレスを返します。クライアントが見つからない場合は nullを返します。

クライアントアドレスのピアレジストリを作成するには、すべてのクライアントアドレスを返すヘルパー関数を作成します。

function getClientRedirectAddrs(client)

{

var redirectAddresses = client.reportedAddresses.slice(0);

redirectAddresses.push(client.farAddress);

redirectAddresses.concat(client.potentialNearAddresses);

return redirectAddresses;

}

クライアントが RTMFPを経由して接続すると、クライアントがピアレジストリに追加されます。

application.onConnect = function(client) {

if (client.protocol == "rtmfp")

{

addClient(client.farID, getClientRedirectAddrs(client));

client.onFarAddressChange = function() {

updateClient(this.farId, getClientRedirectAddrs(client));

};

client.onReportedAddressesChange = function() {

updateClient(this.farId, getClientRedirectAddrs(client));

};

}

}

application.onDisconnect = function(client) {

removeClient(client.farId);

}

application.onPeerLookup() コールバック関数のリダイレクトメッセージと応答 Hello メッセージを送信します。

application.onPeerLookup = function(event) {

// Check whether the target peer is local

// (connected to the same server as the initiating peer).

var targetPeer = getClientIfLocal(event.targetPeerID);

if (targetPeer)

{

// Send the addresses of the target peer to the initiating peer.

application.sendPeerRedirect(getClientRedirectAddrs(targetPeer), event);

// Note: getClientIfLocal() must return the actual client object,

// because that allows us to call introducePeer()

// The target peer sends a responder hello to the initiating peer.

targetPeer.introducePeer(event.initiatorAddress, event.tag);

}

else

{

// Client is not connected locally.

targetPeerAddrs = getRemoteClientAddrs(event.targetPeerID);

if (!targetPeerAddrs)

{

// Returning without calling application.sendPeerRedirect()

// prevents the peer-to-peer connection.

return;

}

// Send the addresses of the target peer to the initiating peer.

application.sendPeerRedirect(targetPeerAddrs, event);

}

}

2 台の Adobe Media Server（サーバー A とサーバー B）の紹介者に対して前記のコードが使用される次のシナリオを考えます。クライアント1 はサーバーA に、クライアント 2 はサーバー B に接続されています。クライアント 1 はクライアント 2 への接続を望んでいます。

•   クライアント 1 はサーバー A にピア参照要求を送信します。

•    ピア参照要求は、サーバーサイドスクリプトの application.onPeerLookup()コールバック関数を呼び出します。

•   クライアント 2 はサーバー A に接続されず、相応のローカルクライアントオブジェクトがないため、else コードブランチが実行されます。サーバー A は getRemoteClientAddrs() を呼び出して、共有ストアからターゲットアドレスを取得します。これらのアドレスには、（クライアント 2 が直接接続されている）サーバー B のアドレスが含まれます。スクリプトは application.sendPeerRedirect() を呼び出し、ターゲットアドレスをクライアント 1 に渡します。

•   リダイレクトがクライアント 1 に到着すると、Flash Player がピア参照要求をサーバー B のアドレスを含む、すべてのターゲットアドレスに送信します。

•  要求がサーバー Bに到着するときに、ローカルターゲットオブジェクトがあるため、ifコードブランチが実行されます。コードは sendPeerRedirect()をもう一度呼び出して、情報をクライアント 1に送信します。ただし、現在はスクリプトにサーバー B のクライアント 2 を表すクライアントオブジェクトがあるため、クライアント 2 で introducePeer()も呼び出すことができます。この呼び出しは、クライアント 2 にクライアント 1 へのパケットの送信を開始するように指示します

（クライアント 1はサーバー Aから最初の sendPeerRedirect()アドレスを取得したため、クライアント 2にパケットを送信しようとしています）。

•   両方のクライアントが互いにトラフィックを送信している場合は、必然的に NATホールパンチングが発生します。両方のクライアントは互いのトラフィックを確認し、ピアツーピア接続を確立できます（両方のクライアントが行儀のよい NATの内側にあることが前提となります）。

紹介要求のフィルター処理

Flash Media Server 4.5

配信された紹介 APIを使用して、紹介要求をフィルター処理することもできます。次のサンプルスクリプトは、ピア IDとクライアントアドレスのマップを作成します。サーバーがピア参照要求を受信すると、application.onPeerLookup() コールバックによってターゲットピアがマップにあるかどうかがチェックされます。マップにない場合、サーバーは参照要求を拒否します。

// A registry mapping peer ID values to Client objects

// for this application instance.

var peerIDToClientMap = {};

// On client connect, add RTMFP clients to the peer ID registry.

application.onConnect = function(client) {

if (client.protocol == "rtmfp")

peerIDToClientMap[client.farID] = client;

}

//

application.onPeerLookup = function(event) {

var targetPeer = peerIDToClientMap[event.targetPeerID];

if(!targetPeer){

// Returning without calling application.sendPeerRedirect()

// prevents the peer-to-peer connection.

return;

}

}

これらの API の詳細については、「サーバーサイド ActionScript リファレンスガイド」を参照してください。

配信された紹介を監視する Administration API の使用

getServerStats() Administration API メソッドの呼び出しで返された次のプロパティを使用して、配信された紹介を監視します。

•    rtmfp_forwards

•    rtmfp_lookups

•    rtmfp_lookups_denied

•    rtmfp_redirects

これらの統計を使用する多くの方法があります。参照数からリダイレクト数を引くと、無視または拒否された参照クエリーの数が得られます。リダイレクト数から転送数を引くと、参照を開始したクライアントが別の Adobe Media Serverノードにリダイレクトされてターゲットピアに接続した参照の数が得られます。rtmfp_lookups_denied統計は、明示的に拒否された参照（例えば、無効な参照であるため）の数を追跡するカウンターです。これは、application.denyPeerLookup() が呼び出されるとインクリメントされます。拒否の数が多すぎる場合、DOS攻撃を示している可能性があります。

getServerStats() Administration API メソッドの呼び出しで返された次のプロパティを使用して、グループに参加およびグループから退出するピアを監視します。

•    group_join

•    group_leave

最終更新日 2013/9/30