JP2002135307A - ストリーム状態通知方法および装置、ならびにプログラム記録媒体 - Google Patents

Abstract

(57)【要約】 【課題】大規模ストリーム配信を行う際に、輻輳状態に
応じてサーバ側の状態をクライアントに通知することが
でき、クライアント側からの再要求によるさらなる要求
過多を防止でき、効率的にクライアントの配信要求処理
を行う。 【解決手段】回線１０１を介してクライアントからのパ
ケットを受信部１０３で受信し、共通メモリ１０４に書
込み、プロトコル処理部１０９で解析してストリーム設
定要求プロトコルであることを同定し、計数部１１０で
計数した現在配信中のストリームコネクション数と設定
部１１２で設定された閾値とを比較部１１１で比較し
て、コネクション数が閾値より大きい場合には、輻輳状
態である旨を通知する情報をコンテンツ格納部１０８か
ら読み出し、送信部１０２からクライアントに送出す
る。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、大規模ストリーム
配信を行う場合に、クライアントから多数のストリーム
配信要求メッセージが来たときでも、輻輳状況に応じて
サーバ側の状態を通知することが可能なストリーム状態
通知方法および装置、ならびにプログラム記録媒体に関
する。

【０００２】

【従来の技術】従来、インターネット上でストリーム配
信を行う場合、一般的にはストリームコンテンツの要求
および設定を行うストリーム設定プロトコルを用いて、
ストリーム配信するためのコネクションの設定をサーバ
ークライアント間で行う。インターネットの標準化組織
であるＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒ
ｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）で規定されるプロトコ
ルとしては、ＲＴＳＰ（Ｒｅａｌ Ｔｉｍｅ Ｓｔｒｅ
ａｍｉｎｇ Ｐｒｏｔｏｃｏｌ：ＲＦＣ２３２６）が挙
げられる。また、これら以外のプロトコルを用いてスト
リーム配信を行う際にも、上記機能を持ったプロトコル
が利用されている。例えば、Ｍｉｃｒｏｓｏｆｔ社のＭ
ＭＳプロトコルや、Ｒｅａｌ Ｎｅｔｗｏｒｋ社のＰＮ
Ａプロトコルなどが挙げられる。なお、上記のＲＴＳＰ
は、ストリーム配信の制御を行うアプリケーションレベ
ルのプロトコルであって、クライアントからのストリー
ム受信要求や、それに対するサーバからの応答をやりと
りするためのプロトコルである。有名歌手のインターネ
ットライブストリーム放送など、多数の視聴要求がある
ストリームコンテンツの場合、ライブストリーム配信開
始時刻近辺に、ストリーム配信要求がクライアントから
多数送出されてしまうことが多く、サーバでその要求を
受け付けることができなくなってしまい、ストリーム配
信サービスを提供できなくなってしまうという問題が生
じていた。

【０００３】図５は、従来におけるサーバとクライアン
トの接続構成例を示す図、図６はサーバとクライアント
とのストリーム配信要求シーケンスチャートである。従
来のストリーム配信技術では、前述のように、あるスト
リームコンテンツを受信しようとする際には、ストリー
ム設定プロトコルを用いて要求をクライアントから送出
する。多数の視聴要求があるストリームコンテンツの場
合には、クライアントからのストリーム配信要求が集中
してしまい、サーバで要求処理を行うことが困難もしく
は不可能となってしまう場合がある。これを企画輻輳と
呼ぶことがある。この状態におけるサーバとクライアン
トとのシーケンス例を説明する。図５において、ストリ
ームサーバ装置１００が配信網２００を介して複数のク
ライアント３００ａ〜３００ｄと接続されている。この
場合のストリームサーバ装置１００とクライアント３０
０ａとのストリーム配信要求シーケンスは、図６のよう
になる。先ず、クライアント３００ａは、受信要求する
ストリームコンテンツに対して、Ｒｅｑｕｅｓｔメッセ
ージａをサーバ１００に対して送出する。

【０００４】ところが、企画輻輳時には、サーバ１００
では、他のクライアントからの要求が多数到着してしま
っているために、それらのメッセージの処理が行えない
状態になってしまい、応答をクライアント３００ａに対
して送出することができない。クライアント３００ａで
は、メッセージａに対する応答が帰ってこないため、ス
トリーム配信プロトコルで規定されたタイムアウト時
間、もしくは通常、ストリーム配信プロトコルはＴＣＰ
（Ｔｒａｎｓｍｉｓｓｉｏｎ ＣｏｎｔｒｏｌＰｒｏｔ
ｏｃｏｌ）を用いているために、ＴＣＰのタイムアウト
時間まで処理を待ち続ける。次に、上記いずれかのタイ
ムアウト時間が過ぎると、クライアント３００ａは本ス
トリーム配信要求を削除し、コネクション設定リソース
の開放を行うために、Ｄｉｓｃｏｎｎｅｃｔメッセージ
ｂをサーバ１００に対して送出する。サーバ１００は、
このメッセージｂの処理が行えない場合、メッセージａ
と同様にタイムアウト時間まで処理を待ち続ける。タイ
ムアウト時間まで待ったにもかかわらず、応答メッセー
ジが帰ってこない場合には、ＦＩＮメッセージｃを送出
し、クライアント側のストリーム要求処理およびコネク
ション設定リソースの開放を行う。

【０００５】

【発明が解決しようとする課題】前述のように、企画
輻輳時に、サーバから応答がない場合には、要求を出し
たクライアントはタイムアウト時間まで処理を待ち続け
るため、無駄なリソースや時間を消費してしまってい
た。 ストリームクライアントの中には、要求処理待ち時に
は、他のアプリケーション処理を受け付けないものもあ
り、ストリームコンテンツを視聴しようとするユーザに
対して非常に大きなストレスを与えているという問題点
があった。 この場合、ユーザに対してはどのような理由で処理待
ちとなっているのかが分からないため、ネットワークに
不具合があるのか、サーバに不具合が生じているのかが
分からない、という問題点もあった。 また、ストリームサーバの中には、接続上限値を事前
に設定し、それ以上の要求があった場合には、受け付け
を拒否するものもあるが、この場合、ユーザは配信要求
が受け付けられるまで、要求を送信し続けることが多々
あり、この結果、サーバに対してさらに多くの配信要求
が到着することになってしまい、さらに長時間の企画輻
輳が起こってしまうという問題点もあった。

【０００６】そこで、本発明の目的は、これら従来の課
題を解決し、大規模なストリーム配信を行う際に、クラ
イアントから多数のストリーム配信要求メッセージが来
たときでも、輻輳状況に応じてサーバ側の状態を通知す
ることが可能なストリーム状態通知方法および装置、な
らびにプログラム記録媒体を提供することにある。

【０００７】

【課題を解決するための手段】上記目的を達成するた
め、本発明のストリーム状態通知方法は、クライアン
トから送信されたパケットを受信し、当該パケットのヘ
ッダ情報を解析してストリーム設定要求プロトコルであ
ることを同定し、現在配信中のストリームコネクション
数と閾値とを比較して、上記ストリームコネクション数
が閾値より大きい場合には、輻輳状態である旨を通知す
る情報を送出することを特徴としている。 また、現在配信中のストリームの総帯域と回線利用上
限値とを比較することも特徴としている。 要求を送信してきたクライアントが再度要求を出すま
での待ち時間を算出し、その待ち時間を通知して、待ち
時間経過後に同一要求プロトコルをクライアントから送
出させることも特徴としている。

【０００８】本発明のストリーム状態通知装置は、ク
ライアントから送出されたパケットを受信する手段と、
当該パケット情報を解析して、ストリーム設定要求プロ
トコルであることを同定する手段と、現在配信中のスト
リームコネクション数を計数して、計数結果を記憶する
手段と、閾値を設定して、該閾値を記憶する手段と、上
記コネクション数と上記閾値とを比較する手段と、メッ
セージを生成する手段とを具備することを特徴としてい
る。 また、現在配信中のストリームの総帯域を算出する手
段と、回線利用上限値を設定する手段と、上記ストリー
ム総帯域と上記回線利用上限値とを比較する手段とを具
備することも特徴としている。 また、待ち時間を算出する手段を具備することも特徴
としている。上記構成を持つことにより、クライアント
から多数のストリーム配信要求メッセージを受信した際
に、輻輳状況に応じてサーバ側の状態を通知することが
可能になり、さらに再要求をクライアント側で送出する
時間をサーバ側で設定することにより、クライアント側
からの再要求によるさらなる要求過多を防止することが
可能になる。その結果、効率的にクライアントの配信要
求処理を行うことが可能になる。

【０００９】

【発明の実施の形態】以下、本発明の実施例を、図面に
より詳細に説明する。 （第１の実施例）図１は、本発明の第１の実施例を示す
ストリーム状態通知装置のブロック図である。本実施例
のストリーム状態通知装置は、図５に示すストリームサ
ーバ装置１００に実装されるものである。ストリームサ
ーバ装置１００は、収容する回線１０１と、回線１０１
にメッセージパケットを送信する送信部１０２、共通メ
モリ１０４からメッセージパケットのヘッダ情報を読み
出して処理をする読出処理部１０３と、メッセージやデ
ータを記憶する共通メモリ１０４と、回線１０１からの
メッセージパケットを受信する受信部１０５と、受信し
たメッセージを共通メモリ１０４に書き込む書込処理部
１０６と、ストリームを生成して共通メモリ１０４に書
き込むストリーム生成部１０７と、テキスト、静止画、
動画、音声などを含む素材であるコンテンツを格納して
おくコンテンツ格納部１０８と、パケットのヘッダ情報
を解析して、プロトコル処理を行うプロトコル処理部１
０９と、現在までのコネクション数を計数するコネクシ
ョン計数部１１０と、コネクション数の限界を示す閾値
を設定する閾値設定部１１２と、現在までのコネクショ
ン数と設定された閾値とを比較する閾値比較部１１１と
から構成されている。

【００１０】第１の実施例では、コネクション計数部１
１０と閾値設定部１１２と閾値比較部１１１が新たに設
置され、また従来から存在しているコンテンツ格納部１
０８に輻輳を示すコンテンツを格納しておき、輻輳時
に、エラー情報を送出するのみならず、輻輳を示すコン
テンツをストリーム配信する点が新規事項である。すな
わち、第１の実施例では、予めこれ以上のコネクション
数に到達したとき輻輳状態になるという限界値（閾値）
を設定し、コネクションを設定する毎に比較部１１１で
閾値と比較していき、閾値を超えた時点で輻輳状態と判
断するのである。待ち時間やコネクションの総帯域に関
係なく、コネクション数だけで輻輳状態を決定するもの
である。

【００１１】図２は、本発明の第１の実施例を示すスト
リーム装置とクライアントとのストリーム設定プロトコ
ルの流れのシーケンスチャートである。なお、図２で
は、クライアントからのストリーム配信要求が多数到着
している企画輻輳の状態となっている場合について説明
する。 （ストリーム装置１００でのメッセージａの処理） １）輻輳時、プロトコル処理部１０９において、現在輻
輳中である旨を記載したＲｅｓｐｏｎｓｅメッセージを
生成し、共通メモリ１０４に書き込み、送出する。 ２）プロトコル処理部１０９からストリーム生成部１０
７に対して、輻輳状態を示すコンテンツ（Ａ）のストリ
ーム配信を指示する。 ３）ストリーム生成部１０７は、その指示に従い、コン
テンツ格納部１０６に格納されたコンテンツＡを取り出
し、ストリーム配信可能なパケットに変換して、共通メ
モリ１０４に書き込み、クライアント３００ａに対して
ストリーム配信を行う。ストリーム装置１００は、上記
のような流れに従って処理を行う。図２のシーケンス
で、Ｒｅｑｕｅｓｔ／ＲｅｓｐｏｎｓｅメッセージはＲ
ＴＳＰプロトコルを用いてやりとりされ、ストリーム配
信はＲＴＰプロトコルを用いて行われる。上記のＲＴＰ
は、ストリームコンテンツの入ったパケットをカプセル
化して転送するためのプロトコルである。

【００１２】先ず、クライアント３００ａから、あるス
トリームコンテンツを受信するための要求を行うため
に、ストリーム設定プロトコルを用いて、Ｒｅｑｕｅｓ
ｔメッセージａをストリームサーバ装置１００に対して
送出する。ストリームサーバ装置１００においては、図
１に示す回線１０１を介してそのメッセージａを受信部
１０５で受信する。受信したメッセージを書込処理部１
０６により共通メモリ１０４に書き込む。次に、プロト
コル処理部１０９によりそのメッセージの解析を行い、
ストリーム設定要求プロトコルであることを同定する。
次に、コネクション計数部１１０により計数された現在
配信中のストリームコネクション数と、閾値設定部１１
２により事前に設定された閾値とを、閾値比較部１１１
において比較する。比較の結果、現在のコネクション数
が設定された閾値を超えている場合には、プロトコル処
理部１０９が現在輻輳中である旨を記載したＲｅｓｐｏ
ｎｓｅメッセージを生成し、共通メモリ１０４に書き込
むことにより、読出処理部１０３がこれを読み出して、
送信部１０２から回線１０１を介してクライアント３０
０ａにＲｅｓｐｏｎｓｅメッセージｄを送信する。次
に、プロトコル処理部１０９からストリーム生成部１０
７に対して輻輳状態を示すコンテンツ（Ａ）のストリー
ム配信を指示する。これにより、ストリーム生成部１０
７はその指示に従ってコンテンツ格納部１０８から該当
するコンテンツＡを取り出し、ストリーム配信可能なパ
ケットに変換して、これを共通メモリ１０４に書き込
む。読出処理部１０３がこれを読み出して送信部１０２
に渡すことにより、送信部１０２から回線を介してクラ
イアント３００ａにストリーム配信を行う。

【００１３】（クライアント３００ａでのメッセージｄ
の処理）図示省略しているが、クライアント３００ａの
端末構成は、受信部と表示部とから構成される。クライ
アント３００ａは、メッセージｄを受信すると、受信処
理を行った後、メッセージｄ中に格納されたコンテンツ
の表示処理を行い、画面に表示する。以上のようにし
て、第１の実施例では、クライアントから多数のストリ
ーム配信要求メッセージが来ることにより企画輻輳が生
じた場合、サーバ側の状態をクライアントに対して通知
することが可能になる。その結果、クライアント側は、
どのような理由で要求されたストリームコンテンツの配
信が行われないのかを知ることができる。また、ストリ
ームサーバ装置１００からの応答コンテンツの表示終了
まで、クライアントでの再要求を待たせることが可能と
なるため、さらなる企画輻輳を防止することができる。
なお、本実施例では、コネクション数と設定された閾値
とを比較したが、現在の配信ストリーム総帯域を計測し
て、予め定められた回線利用可能な上限値と比較するこ
とによっても、上記説明と同様の処理を行うことができ
る。また、本実施例では、ストリーム状態通知装置をス
トリームサーバ装置１００に実装した例を説明したが、
ストリームサーバ機能を有する配信装置に実装しても差
し支えない。

【００１４】（第２の実施例）図３は、本発明の第２の
実施例を示すストリーム状態通知装置の構成図である。
図３に示すように、本実施例が第１の実施例と異なる点
は、クライアントの再要求送出までの待ち時間を算出す
る待ち時間算出部１１３と、メッセージを生成するメッ
セージ生成部１１４が追加されていることである。その
他の構成は、図１と殆んど同じである。なお、待ち時間
算出部１１３は、メッセージを送出してきたクライアン
トが当該コンテンツに対して再要求を送出することが可
能になる時間を乱数により算出するものであり、メッセ
ージ生成部１１４は、待ち時間算出部１１３で算出され
た待ち時間（Ｄｕｒａｔｉｏｎ）情報を内容とするテキ
ストを生成するものである。また、メッセージ生成部１
１４とストリーム生成部１０７との機能上の相違点を述
べると、メッセージ生成部１１４は、待ち時間メッセー
ジ入りコンテンツを生成して、コンテンツ格納部１０８
に格納する処理部であるのに対して、ストリーム生成部
１０７は、コンテンツ格納部１０８に格納されているコ
ンテンツを取り出し、これをストリームパケットに変換
して共通メモリ１０４に書き込む処理を行う処理部であ
る。本実施例によれば、ストリームサーバ装置側におい
て、クライアントにおける再要求までの時間を管理する
ことができるので、再要求メッセージを効率的に処理で
きる。

【００１５】図４は、図３におけるストリームサーバ装
置とクライアントとのストリーム設定プロトコルの流れ
のシーケンスチャートである。なお、本実施例では、第
１の実施例と同様に、クライアントからのストリーム配
信要求が多数到着している企画輻輳の状態になっている
場合について説明する。 （ストリームサーバ装置１００でのメッセージａの処
理）第２の実施例に関して、ストリームサーバ装置１０
０の処理は、下記のように整理される。 １）輻輳時、プロトコル処理部１０９において、現在輻
輳中である旨を記載したＲｅｓｐｏｎｓｅメッセージを
生成し、共通メモリ１０４に書き込み、これを送出す
る。 ２）待ち時間算出部１１３により再要求可能な時間とし
て待ち時間（Ｄｕｒａｔｉｏｎ）を算出し、メッセージ
生成部１１４に通知する。 ３）メッセージ生成部１１４では、通知された待ち時間
に応じたメッセージを含んだ、輻輳状態を示すコンテン
ツを作成し、コンテンツ格納部１０８に格納する。 ４）プロトコル処理部１０９からストリーム生成部１０
７に対して、輻輳状態を示すコンテンツ（Ａ）のストリ
ーム配信を指示する。 ５）ストリーム生成部１０７は、その指示に従ってコン
テンツ格納部１０８に格納されたコンテンツＡを取り出
し、ストリーム配信可能なパケットに変換して、共通メ
モリ１０４に書き込み、クライアントに対してストリー
ム配信を行う。

【００１６】以下、第２の実施例の動作を述べる。先
ず、クライアント３００ａから、あるストリームコンテ
ンツを受信するための要求を行うために、ストリーム設
定プロトコルを用いてＲｅｑｕｅｓｔメッセージａをス
トリームサーバ装置１００に対して送出する。ストリー
ムサーバ装置１００は、受信したメッセージａの受信処
理および解析処理を行い、ストリーム設定要求プロトコ
ルであることを同定する。なお、第１図の第１の実施例
による処理と同じ場合には、説明を省略する。次に、現
在配信中のストリームコネクション数と設定された閾値
とを、閾値比較部１１１により比較し、比較の結果、コ
ネクション数が閾値を超えている場合には、プロトコル
処理部１０９は現在輻輳中である旨を示すＲｅｓｐｏｎ
ｓｅメッセージｅを生成し、これを共通メモリ１０４に
書き込む。次に、読出処理部１０３が共通メモリ１０４
からこのＲｅｓｐｏｎｓｅメッセージｅを読み出し、送
信部１０２から回線１０１を介してクライアント３００
ａに送信する。次に、待ち時間算出部１１３により当該
クライアントが当該コンテンツに対して再要求を送出す
ることが可能になる時間を乱数により算出し、その値を
Ｄｕｒａｔｉｏｎ情報とする。このＤｕｒａｔｉｏｎ情
報をメッセージ生成部１１４に通知すると、メッセージ
生成部１１４は、コンテンツ格納部１８から通知された
待ち時間に応じたメッセージを含んだ、輻輳状態を示す
コンテンツを作成し、コンテンツ格納部１０８に格納す
る。次に、プロトコル処理部１０９からストリーム生成
部１０７に対して、輻輳状態を示すコンテンツ（Ａ）の
ストリーム配信を指示することにより、ストリーム生成
部１０７は、その指示に従ってコンテンツ格納部１０８
に格納されたコンテンツＡを取り出し、ストリーム配信
可能なパケットに変換して、共通メモリ１０４に書き込
む。読出処理部１０３は、共通メモリ１０４からストリ
ーム配信可能なパケットを読み出し、送信部１０２から
回線１０１を介してクライアント３００ａに対してスト
リーム配信を行う。

【００１７】（クライアント３００ａでのメッセージｅ
の処理）ストリームサーバ装置１００から送出されたＲ
ｅｓｐｏｎｓｅメッセージｅは、配信網２００を介して
クライアント３００ａに到着する。クライアント３００
ａは、メッセージｅの受信処理を行い、メッセージｅ中
に格納されているコンテンツの表示処理を行い、画面に
表示する。さらに、クライアント３００ａは、図４に示
すように、メッセージ中に格納されたＤｕｒａｔｉｏｎ
情報の時間だけ、コンテンツ配信要求の再送出を待つ。
Ｄｕｒａｔｉｏｎ時間の経過後、クライアント３００ａ
は、ストリームサーバ装置１００に対して再度Ｒｅｑｕ
ｅｓｔメッセージａを送出する。ストリームサーバ装置
１００は、当該メッセージａを処理し、ストリーム配信
処理が可能となっていれば、Ｒｅｓｐｏｎｓｅメッセー
ジｆをクライアント３００ａに対して送出する。このＲ
ｅｓｐｏｎｓｅメッセージｆには、クライアントが要求
しているストリームコンテンツの配信が可能である旨が
記載されている。従って、その後、通常のコネクション
設定処理が行われ、その後に要求したストリームコンテ
ンツのストリーム配信が行われる。もし、Ｄｕｒａｔｉ
ｏｎ時間待たせたにもかかわらず、未だ企画輻輳が終了
していない場合には、待ち時間算出部１１３により再度
待ち時間を算出し、メッセージ生成部１１４でＲｅｓｐ
ｏｎｓｅメッセージｆを生成し、再度送信部１０２から
クライアント３００ａに対して輻輳状態である旨を通知
する。

【００１８】以上のようにして、第２の実施例において
は、クライアントから多数のストリーム配信要求メッセ
ージが来たことにより企画輻輳が生じた時、サーバ側の
状態をクライアントに対して通知することが可能にな
り、クライアント（ユーザ）はどのような理由で要求さ
れたストリームコンテンツの配信が行われないのかを知
ることができる。また、クライアントからの再要求を、
ストリームサーバ装置側で管理することができるので、
クライアントからの再要求メッセージを効率的に処理す
ることが可能になる。なお、本実施例では、待ち時間を
乱数により定めているが、ある分布関数に従って待ち時
間を定めても構わない。

【００１９】図２および図４に示す第１の実施例および
第２の実施例の処理シーケンスチャートをプログラムに
変換し、変換されたプログラムをＣＤ−ＲＯＭなどの記
録媒体に格納しておけば、この記録媒体を任意のコンピ
ュータに実装し、プログラムをインストールした後、実
行することにより、本発明が容易に実現できる。また、
プログラムをネットワークを介して他のコンピュータに
ダウンロードして、実行させることにより、任意の他の
コンピュータにおいても本発明が容易に実現できる。

【００２０】

【発明の効果】以上説明したように、本発明によれば、
大規模ストリーム配信を行う際に、クライアントから多
数のストリーム配信要求メッセージが来た場合でも、輻
輳状態に応じてサーバ側の状態をクライアントに通知す
ることができるとともに、さらにクライアント側から再
要求を送出する時間をサーバ側で設定することができる
ので、クライアント側からの再要求によるさらなる要求
過多を防止することができ、効率的にクライアントの配
信要求処理を行うことが可能となる。

【図面の簡単な説明】

【図１】本発明の第１の実施例を示すストリーム状態通
知装置の構成図である。

【図２】本発明の第１の実施例を示すサーバとクライア
ントのストリーム設定プロトコルの流れのシーケンスチ
ャートである。

【図３】本発明の第２の実施例を示すストリーム状態通
知装置の構成図である。

【図４】本発明の第２の実施例を示すサーバとクライア
ントのストリーム設定プロトコルの流れのシーケンスチ
ャートである。

【図５】従来におけるサーバとクライアントの接続構成
図である。

【図６】従来におけるサーバとクライアントのストリー
ム配信要求シーケンスチャートである。

【符号の説明】

１００…ストリームサーバ装置、１０１…回線、１０２
…送信部、１０３…読出処理部、１０４…共通メモリ、
１０５…受信部、１０６…書込処理部、１０７…ストリ
ーム生成部、１０８…コンテンツ格納部、１０９…プロ
トコル処理部、１１０…コネクション計数部、１１１…
閾値比較部、１１２…閾値設定部、１１３…待ち時間算
出部、１１４…メッセージ生成部、２００…配信網、３
００ａ〜３００ｄ…クライアント。

Claims (7)

【特許請求の範囲】
1. 【請求項１】 ストリーム配信ネットワークにおいて、 クライアントから送出されたパケットを受信し、 該パケットのヘッダ情報を解析して、ストリーム設定要
   求プロトコルであることを同定し、 現在配信中のストリームコネクション数と予め設定され
   た閾値とを比較し、 比較の結果、上記コネクション数が閾値よりも大きい場
   合には、輻輳状態であることを示す情報を上記クライア
   ントに送信することを特徴とするストリーム状態通知方
   法。
2. 【請求項２】 請求項１に記載のストリーム状態通知方
   法において、 前記現在配信中のストリームコネクション数と閾値を比
   較する代りに、現在配信中のストリームの総帯域と、回
   線利用上限値とを比較して、総帯域が上限値より大きい
   ときに輻輳状態であることを示す情報を送信することを
   特徴とするストリーム状態通知方法。
3. 【請求項３】 請求項１に記載のストリーム状態通知方
   法において、 前記クライアントが再度ストリーム設定要求を出すまで
   の待ち時間を算出し、 算出した待ち時間の経過後に、同一要求プロトコルを該
   クライアントから送出させることを特徴とするストリー
   ム状態通知方法。
4. 【請求項４】 ストリーム配信ネットワークにおいて、 クライアントから送出されたパケットを受信する手段
   と、当該パケットのヘッダ情報を解析し、ストリーム設
   定要求プロトコルであることを同定する手段と、 現在配信中のストリームコネクション数を計数して、計
   数結果値を記憶する手段と、予め閾値を設定して、設定
   された閾値を記憶する手段と、上記コネクション数と上
   記閾値とを比較する手段と、比較の結果に応じて上記ク
   ライアントへのメッセージを生成する手段とを具備する
   ことを特徴とするストリーム状態通知装置。
5. 【請求項５】 請求項４に記載のストリーム状態通知装
   置において、 前記ストリームコネクション数計数手段に代って、ある
   いは追加して、現在配信中のストリームの総帯域を算出
   する手段と、 前記閾値設定手段に代って、あるいは追加して、回線利
   用上限値を設定する手段と、 前記コネクション数と閾値とを比較する手段に代って、
   あるいは追加して、該ストリームの総帯域と該回線利用
   上限値とを比較する手段とを具備することを特徴とする
   ストリーム状態通知装置。
6. 【請求項６】 請求項４に記載のストリーム状態通知装
   置において、 前記各手段に加えて、待ち時間を算出する手段を具備す
   ることを特徴とするストリーム状態通知装置。
7. 【請求項７】 請求項１項ないし３項のいずれかに記載
   のストリーム状態通知方法の各処理ステップをプログラ
   ムに変換し、該プログラムを記録媒体に記録したことを
   特徴とするコンピュータで読み取り可能なプログラム記
   録媒体。