JP3685729B2 - マルチコネクション接続装置及びマルチコネクション接続制御方法 - Google Patents
マルチコネクション接続装置及びマルチコネクション接続制御方法 Download PDFInfo
- Publication number
- JP3685729B2 JP3685729B2 JP2001084708A JP2001084708A JP3685729B2 JP 3685729 B2 JP3685729 B2 JP 3685729B2 JP 2001084708 A JP2001084708 A JP 2001084708A JP 2001084708 A JP2001084708 A JP 2001084708A JP 3685729 B2 JP3685729 B2 JP 3685729B2
- Authority
- JP
- Japan
- Prior art keywords
- connection
- client
- stream
- request
- server
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、音声・映像等を含むストリーム放送を、インターネットを介して大規模に配信するのに好適な、マルチコネクション接続装置及びマルチコネクション接続制御方法に関するものである。
【０００２】
【従来の技術】
近年、家庭にあるパーソナル・コンピュータ端末（以下、単に「クライアント」という）とインターネットを利用したストリーミング放送が普及し始めている。
【０００３】
このストリーミング放送は、既存のテレビ放送と比較して映像品質が悪く、現段階では広範囲に普及しているとは言えないが、将来的に、中継回線及び加入者回線の広帯域化に伴い、高品質の映像の配信が可能となって、現在のテレビ放送に匹敵する視聴メディアになるものと予想されている。
【０００４】
現行のストリーミング放送は、既存のテレビ放送における配信形態とは大きく異なり、インターネットに接続されている全ての端末に向けて放送を行う必要はなく、視聴を希望する視聴者の端末にのみ配信される。この結果、ストリーミング放送における配信範囲及び配信数は、各クライアントの受信要求により、放送コンテンツのジャンルや配信時刻（放送時刻）などによって様々に変化する。
【０００５】
ここで、インターネットは、既知のように大部分が有線の地上回線で構成されているが、この地上回線を利用したストリーミング放送の伝送コストは、所要のストリーム番組を、狭範囲に分布する少数の視聴者に向けて配信する場合には減少し、広範囲に分布する多数の視聴者に配信する場合には増大する。
【０００６】
さらに、ストリーミング放送に地上回線を使用する場合、視聴者が急激に増加すると、輻輳に伴う伝搬遅延やパケットロスなどにより、その映像品質が極端に劣化することがある。こうした現状を考慮して、既存の地上回線によるインターネットを利用することなく、各家庭に衛星受信装置を設置し、常にほぼ一定の通信品質が保証された衛星回線を経由して、所要のストリーミング放送を提供するサービスが考え出されている。
【０００７】
図１０は、従来のストリーム配信システムの一例を示す模式接続図である。
従来のストリーム配信システムでは、ストリーム番組の送信元となるストリームサーバ１と、ストリーム番組を受信する複数のクライアント５，５１，５２，５３，５ｎとの間に、中継装置となるスプリッタ２０（プロキシーとも呼ばれる）を配置した構成となっている。
【０００８】
スプリッタ２０としては、Real Net works社のスプリッタ製品が代表的なものとなっている。これは、汎用パソコン又は汎用ワークステーションなどの汎用プロセッサ上で動作し、ストリームサーバ１から受信したストリーム番組（パケット）を、１又は複数のクライアント５，５１，５２，５３，５ｎに対して、コピーして配信するものである。
【０００９】
【発明が解決しようとする課題】
しかしながら、従来のストリーム配信システムにおいては、複数のクライアント５，５１，５２，５３，５ｎからのストリーム配信コネクション４，４１，４２，４３，４ｎを、そのクライアントの数に対応した複数のＴＣＰコネクション３０を用いて、それぞれストリームサーバ１に接続している。なお、ＴＣＰコネクションとは、インターネットで利用される標準プロトコルであるＴＣＰ（Transmission Control Protocol）での接続であり、ＯＳＩ参照モデルのトランスポート層にあたる。また、ストリーム配信コネクション４，４１，４２，４３，４ｎも、それぞれＴＣＰプロトコルによる接続である。
【００１０】
即ち、従来装置のスプリッタ２０は、多数の複数のクライアント５，５１，５２，５３，５ｎそれぞれからストリーム番組の配信要求を受け、その多数の配信要求それぞれを個別にストリームサーバ１に送信している。従って、従来装置のスプリッタ２０では、複数のクライアント５，５１，５２，５３，５ｎが同じストリーム番組についての配信要求をした場合でも、ストリームサーバ１に対して、各クライアント５，５１，５２，５３，５ｎの配信要求ごとにＴＣＰコネクションを行なう接続処理をする必要があった。
【００１１】
これにより、クライアント５の数が増えるほど配信要求についての接続処理が増大するので、多数のクライアント５へストリーム番組を配信する大規模なストリーム放送は、ストリームサーバ１の過負荷となり、且つ、伝送コストも過大となるので、従来のストリーム放送技術では実現が困難であるという問題点があった。換言すれば、従来は、複数のクライアント５からの配信要求ごとにストリームサーバ１に対してコネクション接続処理が必要であったので、ストリームサーバ１の過負荷となり、伝送コストが過大になるという第１の問題点があった。
【００１２】
次に、上述の第１の問題点を解決するために、ストリームサーバ１との接続を行わずに、各クライアント５の配信要求についての処理であるメッセージ処理を終端する（自分で実行する）スプリッタを考えることができる。
【００１３】
しかしながら、このようなメッセージ処理を終端するスプリッタでは、各クライアント５の認証、各クライアント５のプロフィールの取得、ストリーム放送についての統計及びストリーム番組を受信した各クライアント５に対する課金等からなるクライアント固有情報を、収集することができない。
【００１４】
そこで、上述のようなメッセージ処理を終端するスプリッタでは、ストリームサーバ１におけるコネクション接続処理は低減するが、当該スプリッタにおけるメッセージ処理についての負荷が増大し、更に、各クライアント５，５１，５２，５３，５ｎの認証、各クライアント５，５１，５２，５３，５ｎのプロフィールの取得、ストリーム放送についての統計及びストリーム番組を受信した各クライアント５，５１，５２，５３，５ｎに対する課金等について、サービス性が低減する、という第２の問題点がある。
【００１５】
次に、上述の第２の問題点を解決するためには、各クライアント５，５１，５２，５３，５ｎの認証、各クライアント５，５１，５２，５３，５ｎのプロフィールの取得、ストリーム放送についての統計及びストリーム番組を受信した各クライアント５，５１，５２，５３，５ｎに対する課金等の処理を実行するクライアント固有情報処理機能を、スプリッタに付加させることが考えられる。
【００１６】
しかしながら、このようにクライアント固有情報処理機能をスプリッタに付加させると、ストリームサーバ１において集中管理していた機能が分散されてしまう。特に、複数のスプリッタを用いて、大規模なストリーム配信をする場合には、ストリームサーバ１が持っていた機能の分散化が顕著となる。
【００１７】
そこで、クライアント固有情報処理機能をスプリッタに付加させると、各クライアント５，５１，５２，５３，５ｎの認証、各クライアント５，５１，５２，５３，５ｎのプロフィールの取得、ストリーム放送についての統計、ストリーム番組を受信した各クライアント５，５１，５２，５３，５ｎに対する課金、及び各スプリッタの動作等についての管理が複雑になり、クライアント固有情報処理機能等について各スプリッタごとに設定しなければならないのでその設定コストが増大し、クライアント固有情報処理機能等についての処理オーバーヘッドも増大する、という第３の問題点がある。
【００１８】
ここにおいて、本発明の解決すべき主要な目的は以下の通りである。
即ち、本発明の第１の目的は、多数のクライアントにストリーム放送を配信する大規模なストリーム配信処理を可能とするマルチコネクション接続装置及びマルチコネクション接続制御方法を提供せんとするものである。
【００１９】
本発明の第２の目的は、複数のクライアントからの複数のストリーム配信コネクションを、単一のストリーム配信コネクションとしてまとめて、ストリームサーバに接続することで、ストリームサーバの負荷を軽減し、大規模なストリーム配信処理を可能とするマルチコネクション接続装置及びマルチコネクション接続制御方法を提供せんとするものである。
【００２０】
本発明の第３の目的は、クライアントの配信要求についてのトラザクションをキャッシュ（保持）して、当該保持したものを用いて、複数のクライアントへ配信要求の応答をすることで、マルチコネクション接続装置（スプリッタ）での各クライアントの配信要求について処理負荷を軽減することを可能とするマルチコネクション接続装置及びマルチコネクション接続制御方法を提供せんとするものである。
【００２１】
本発明の第４の目的は、クライアントの各種の配信要求についてのトラザクションを複数キャッシュして、当該複数のトラザクションのなかから所望のトラザクションを選択して実施することを可能として、クライアントの配信要求についてのストリームサーバの負荷を軽減しながら、クライアント固有情報等の所望の情報についてストリームサーバで集中的に管理することを可能とするマルチコネクション接続装置及びマルチコネクション接続制御方法を提供せんとするものである。
【００２２】
本発明の他の目的は、明細書、図面、特に、特許請求の範囲における各請求項の記載から自ずと明らかとなろう。
【００２３】
【課題を解決するための手段】
本発明装置は、上記課題の解決に当たり、クライアントから受信したパケットに含まれているストリームコンテンツ要求情報を解析する要求解析部と、要求解析部が解析したストリームコンテンツ要求情報を格納するメッセージキャッシュ部とを、有し、当該メッセージキャッシュ部は、複数のストリームコンテンツ要求情報を、１つのストリームコンテンツ要求情報をなす代表配信要求にまとめて、サーバ側送受信手段からストリームサーバに送信する仕組みからなる構成手段を講じる特徴を有する。
【００２４】
本発明方法は、上記課題の解決に当たり、複数のクライアントのそれぞれからストリームコンテンツの配信要求を受信し、当該複数の配信要求を１つの配信要求をなす代表配信要求として、１つのＴＣＰプロトコルでの接続でストリームサーバに送信する、構成手法を講じる特徴を有する。
【００２５】
更に、具体的詳細に述べると、当該課題の解決では、本発明が次に列挙する上位概念から下位概念にわたる新規な特徴的構成手段又は手法を採用することにより、上記目的を達成するように為される。
【００２６】
即ち、本発明装置の第１の特徴は、複数のクライアントと単一のストリームサーバ間に介在してコネクション接続するために、ストリームサーバに対してパケットの送受信をするサーバ側送受信手段と、複数のクライアントに対してパケットの送受信をするクライアント側送受信手段と、当該クライアント側送受信手段がクライアントから受信したパケットに含まれているストリームコンテンツ要求情報を解析する要求解析部と、当該要求解析部が解析したストリームコンテンツ要求情報と、前記サーバ側送受信手段が前記ストリームサーバから受信したパケットに含まれている前記クライアントの要求に対するメッセージとなる応答と、を格納するとともに、同一のストリームコンテンツに対する複数のストリームコンテンツ要求情報を、１つのストリームコンテンツ要求情報をなす代表配信要求にまとめ、当該代表配信要求を前記サーバ側送受信手段から前記ストリームサーバに送信させる機能構成をなすメッセージキャッシュ部と、を有するマルチコネクション接続装置であって、前記要求解析部は、前記ストリームコンテンツ要求情報が前記クライアントに固有の情報からなるクライアント固有情報を前記メッセージキャッシュ部に格納していないと判断した場合は、当該ストリームコンテンツ要求情報に対応する処理を実行し、当該ストリームコンテンツ要求情報が当該クライアントに固有の情報からなるクライアント固有情報を前記メッセージキャシュ部に格納していると判断した場合は、当該ストリームコンテンツ要求情報を前記サーバ側送受信手段から前記ストリームサーバへ送信させる機能構成を有してなるマルチコネクション接続装置の構成採用にある。
【００２７】
本発明装置の第２の特徴は、上記本発明装置の第１の特徴における前記コネクションが、単一の前記マルチコネクション接続装置と複数の前記クライアント間は当該クライアント数に対応するストリーム配信コネクションであるマルチコネクション接続装置の構成採用にある。
【００２８】
本発明装置の第３の特徴は、上記本発明装置の第１又は第２の特徴における前記コネクションが、単一の前記マルチコネクション接続装置と前記ストリームサーバ間は単一のＴＣＰコネクションであるマルチコネクション接続装置の構成採用にある。
【００２９】
本発明装置の第４の特徴は、上記本発明装置の第１、第２又は第３の特徴における前記要求解析部が、複数のクライアントからそれぞれ送出される前記ストリームコンテンツ要求情報を、各当該クライアント毎の複数のトラザクションとして、前記クライアント側送受信手段を介して、受信する機能構成をなし、前記メッセージキャッシュ部が、当該要求解析部が複数のクライアントから受信した複数のトラザクションにおける同一のストリームコンテンツについての複数のトラザクションを、前記代表配信要求を行なう１個のトラザクションとして、前記サーバ側送受信手段に送信させる機能構成をなしてなるマルチコネクション接続装置の構成採用にある。
【００３０】
本発明装置の第５の特徴は、上記本発明装置の第１、第２、第３又は第４の特徴における前記クライアント側送受信手段が、複数のクライアントのそれぞれとＴＣＰプロトコルで接続してパケットの送受信をする機能構成をなし、前記サーバ側送受信手段が、前記ストリームサーバに対してのＴＣＰプロトコルを用いた単一接続で、前記代表配信要求を送信する機能構成をなしてなるマルチコネクション接続装置の構成採用にある。
【００３１】
本発明装置の第６の特徴は、上記本発明装置の第１、第２、第３、第４又は第５の特徴における前記クライアント側送受信手段が、複数のクライアント及び／又は下位ストリームサーバのそれぞれとＴＣＰプロトコルで接続してパケットの送受信をする機能構成をなし、前記サーバ側送受信手段が、上位ストリームサーバに対してのＴＣＰプロトコルを用いた単一接続で、前記代表配信要求を送信する機能構成をなしてなるマルチコネクション接続装置の構成採用にある。
【００３２】
本発明装置の第７の特徴は、上記本発明装置の第１、第２、第３、第４、第５又は第６の特徴における前記メッセージキャッシュ部が、前記代表配信要求を、１つの送信元ポート番号と１つの宛先ポート番号とを用いて、１つのアプリケーションから他の１つのアプリケーションに引き渡されるデータとして、前記サーバ側送受信手段から前記ストリームサーバへ送信させる機能構成をなしてなるマルチコネクション接続装置の構成採用にある。
【００３３】
本発明装置の第８の特徴は、上記本発明装置の第１の特徴における前記要求解析部で判断される前記クライアント固有情報が、前記配信要求をしたクライアントの認証、当該クライアントのプロフィール、当該クライアントに対する課金及びストリーム放送についての統計、の内の少なくとも１つについて用いられる情報からなるマルチコネクション接続装置の構成採用にある。
【００３４】
本発明装置の第９の特徴は、上記本発明装置の第１の特徴における前記メッセージキャッシュ部には、前記クライアントの要求に対する、前記ストリームサーバから受信したパケットが格納されており、前記要求解析部は、前記クライアントから受信したパケットに含まれている要求が、前記クライアント情報を格納しておらず、当該メッセージキャッシュ部に予め格納されている当該所定の応答又は、ストリームコンテンツに該当する前記ストリームコンテンツ要求情報であると判断した場合は、前記ストリームサーバに聞きにいくことなく、当該所定の応答を当該クライアントに向けて送信させる、機能構成を有してなるマルチコネクション接続装置の構成採用にある。
【００３８】
本発明方法の第１の特徴は、複数のクライアントと単一のストリームサーバ間にマルチコネクション接続手段を介接したコネクション接続を制御するために、複数のクライアントのそれぞれとＴＣＰプロトコルで接続して、当該複数のクライアントのそれぞれからストリームコンテンツの配信要求を受信し、当該配信要求に対応する応答を保持している場合には、当該応答を当該クライアントに送信するとともに、当該配信要求に対応する応答を保持していない場合には、当該ストリームコンテンツの配信元となるストリームサーバに対して、単一のコネクションで接続して、当該配信要求を代表して送信し、当該配信要求に対するストリームサーバからの応答を保持し、当該応答を、当該配信要求した複数のクライアントに送信するのに先立って、前記クライアントの配信要求が当該クライアントに固有の情報からなるクライアント固有情報を前記マルチコネクション接続手段内に格納していないと判断された場合は、当該配信要求に対応する処理を当該マルチコネクション接続手段内で実行する終端処理を行うとともに、前記クライアントの配信要求が当該クライアントに固有の情報からなるクライアント固有情報を前記マルチコネクション接続手段内に格納していると判断された場合は、当該配信要求を前記ストリームサーバに送信するスルー処理を行なってなるマルチコネクション接続制御方法の構成採用にある。
【００３９】
本発明方法の第２の特徴は、上記本発明方法の第１の特徴における前記クライアント固有情報が、前記配信要求をしたクライアントの認証、当該クライアントのプロフィール、当該クライアントに対する課金及びストリーム放送についての統計、の内の少なくとも１つについて用いられる情報からなるマルチコネクション接続制御方法の構成採用にある。
【００４０】
本発明方法の第３の特徴は、上記本発明方法の第１又は第２の特徴における前記マルチコネクション接続制御方法が、前記クライアントから出された要求が、当該クライアントと前記マルチコネクション接続手段間の接続性を確認するものである場合は、当該マルチコネクション接続手段において事前に保持されている応答を、当該マルチコネクション接続手段が当該クライアントに送信してなるマルチコネクション接続制御方法の構成採用にある。
【００４６】
【発明の実施の形態】
以下、添付図面を参照しながら、本発明の実施の形態を装置例及び方法例につき説明する。
【００４７】
なお、本発明は、複数のクライアントからの要求にかかる複数のストリーム配信コネクションを、単一のストリーム配信コネクションとしてストリームサーバに接続することで、ストリームサーバにおける接続処理についての負荷を低減することに関する発明であるが、本実施形態では、インターネットを介してストリーム番組を配信する形態を挙げて説明するも、本発明はこれ等に限定されるものではなく、インターネット以外の各種の通信網にも適用できる。
【００４８】
（装置例）
図１は、本発明の装置例を示すマルチコネクション接続装置を適用したシステムの接続形態を示す模式図である。
図中、１はストリーム番組をなすパケット（以下、「ストリームパケット」という。）の送信元となるストリームサーバ、２は本発明の装置例であるマルチコネクション接続装置、５，５１，５２，５３，５ｎはストリームパケットを受信する複数のクライアントである。
【００４９】
ここで、ストリームサーバ１とマルチコネクション接続装置２は、ＴＣＰコネクション３で接続される。ＴＣＰコネクション３は、ＴＣＰプロトコルによる接続である。マルチコネクション接続装置２と各クライアント５，５１，５２，５３，５ｎとは、それぞれストリーム配信コネクション４，４１，４２，４３，４ｎで接続される。ストリーム配信コネクション４，４１，４２，４３，４ｎのそれぞれも、ＴＣＰプロトコルによる接続である。
【００５０】
従って、マルチコネクション接続装置２は、複数のクライアント５，５１，５２，５３，５ｎからの複数のストリーム配信コネクション４，４１，４２，４３，４ｎを、その接続数を低減して、ＴＣＰコネクション３として、ストリームサーバ１に接続するものである。
【００５１】
図２は、本発明の装置例であるマルチコネクション接続装置２の主要部を示す概念ブロック図である。
マルチコネクション接続装置２の主要部は、クライアント側送受信手段２１と、要求解析部２２と、メッセージキャッシュ部２３と、サーバ側送受信手段２４とで構成されている。
【００５２】
クライアント側送受信手段２１は、複数のクライアント５，５１，５２，５３，５ｎそれぞれ対して、ＴＣＰプロトコルで接続して、パケットの送受信をするものである。サーバ側送受信手段２４は、ストリームサーバ１に対して、ＴＣＰプロトコルで接続して、パケットの送受信をするものである。
【００５３】
要求解析部２２は、クライアント側送受信手段２１がクライアント５，５１，５２，５３，５ｎから受信したパケットに含まれているストリームコンテンツ要求情報を解析するものである。ここで、要求解析部２２は、複数のクライアント５，５１，５２，５３，５ｎからそれぞれ送出されるストリームコンテンツ要求情報を、各クライアント毎の複数のトラザクションとして、クライアント側送受信手段２１を介して、受信するものである。
【００５４】
メッセージキャッシュ部２３は、要求解析部２２が解析したストリームコンテンツ要求情報を格納するものである。また、メッセージキャッシュ部２３は、同一のストリームコンテンツに対する複数のストリームコンテンツ要求情報を、１つのストリームコンテンツ要求情報をなす代表配信要求にまとめ、当該代表配信要求をサーバ側送受信手段２４からストリームサーバ１に送信させる、ものである。
【００５５】
即ち、メッセージキャッシュ部２３は、要求解析部２２が行なった複数のクライアント５，５１，５２，５３，５ｎについての複数の接続処理（トラザクション）における同一のストリームコンテンツについての複数のトラザクションを、代表配信要求を行なう１個のトラザクションとして、サーバ側送受信手段２４とストリームサーバ１との間で実行させるものである。これにより、サーバ側送受信手段２４は、ストリームサーバ１に対してのＴＣＰプロトコルを用いた１つの接続で、代表配信要求を送信する。
【００５６】
これらにより、マルチコネクション接続装置２は、同一のストリームコンテンツに対して配信要求を行う複数のストリームコンテンツ要求情報を１つのストリームコンテンツ要求情報をなす代表配信要求にまとめて、サーバ側送受信手段２４からストリームサーバ１に送信することができる。従って、ストリームサーバ１において、クライアント５，５１，５２，５３，５ｎからストリームコンテンツ要求についての接続処理（トラザクション）を大幅に低減することができるので、多数のクライアントにストリーム放送を配信する大規模なストリーム配信処理を実現することができる。
【００５７】
メッセージキャッシュ部２３の具体的構成としては、代表配信要求を、１つの送信元ポート番号（マルチコネクション２内の１個のアプリケーションを指すポート番号）と１つの宛先ポート番号（ストリームサーバ１内の１個のアプリケーションを指すポート番号）とを用いて、１つのアプリケーションから他の１つのアプリケーションに引き渡されるデータとして、サーバ側送受信手段２４からストリームサーバ１へ送信させるものとする。
【００５８】
即ち、マルチコネクション接続装置２内の１個のアプリケーションから、ストリームサーバ１内の１個のアプリケーションへ引き渡すデータとして、送信させる。
【００５９】
また、メッセージキャッシュ部２３は、要求解析部２２が解析したストリームコンテンツ要求情報のみならず、サーバ側送受信手段２４がストリームサーバ１から受信したパケットに含まれているものであってクライアント５の要求に対するメッセージとなる「応答」をも、格納するものである。
【００６０】
そして、要求解析部２２は、クライアント５から送られてきたストリームコンテンツ要求情報に対応する「応答」が、メッセージキャッシュ部２３に格納されているか判断する機能を持つ。要求解析部２２は、当該「応答」が格納されていると判断した場合は、当該「応答」をクライアント側送受信手段２１からクライアント５へ送信させる機能も持つ。
【００６１】
要求解析部２２は、当該「応答」がメッセージキャッシュ部２３に格納されていないと判断した場合は、要求されたストリームコンテンツの配信元となるストリームサーバ１に対して、代表配信要求を送信させる機能も持つ。
【００６２】
ここで、当該「応答」とは、クライアント５のストリームコンテンツの要求に対する回答などとなるメッセージであって、ストリームサーバ１からサーバ側送受信手段２４が受信してメッセージキャッシュ部２３に格納されたものである。
【００６３】
これらにより、マルチコネクション接続装置２は、クライアント５の各種のストリームコンテンツ要求に対するトラザクションを「応答」としてメッセージキャッシュ部２３にキャッシュしておき、キャッシュした応答を、複数のクライアント５のストリームコンテンツ要求に用いることができるので、マルチコネクション接続装置２での各クライアント５の配信要求に対する応答メッセージの送信についての処理負荷を軽減することができる。
【００６４】
（方法例１）
前記装置例に適用する本実施形態の方法例１につき、図面を参照して説明する。
【００６５】
先ず、クライアント５，５１，５２，５３，５ｎのそれぞれからストリームコンテンツの配信要求があった場合に、クライアント側送受信手段２１が複数のクライアント５，５１，５２，５３，５ｎのそれぞれとＴＣＰプロトコルで接続して、複数のクライアント５，５１，５２，５３，５ｎのそれぞれからストリームコンテンツの配信要求を受信する。
【００６６】
その後、複数の配信要求を要求解析部２２が解析する。この解析結果に基づいて、メッセージキャッシュ部２３が同一のストリームコンテンツに対する複数の配信要求を、１つの配信要求をなす代表配信要求にまとめる。
その後、サーバ側送受信手段２４がストリームコンテンツの配信元となるストリームサーバ１に対して、１つのトラザクションとしてＴＣＰプロトコルで接続し、代表配信要求を送信する。
【００６７】
ここで、代表配信要求は、１つの送信元ポート番号と、１つの宛先ポート番号とが特定されて、マルチコネクション接続装置２内の１つのアプリケーションから、ストリームサーバ１内の１つのアプリケーションに、引き渡されるデータとして、ストリームサーバ１に送信される。
【００６８】
これらにより、マルチコネクション接続装置２は、ストリームサーバ１との間において、複数のクライアント５，５１，５２，５３，５ｎからの複数のストリームコンテンツの配信要求について、１本の通信路（ＴＣＰコネクション３）で、且つ、アプリケーションにおいても１対１として、処理することができ、ストリームサーバ１の接続処理（トラザクション）を大幅に低減することができる。
【００６９】
（方法例２）
前記装置例に適用する本実施形態の方法例２につき、図面を参照して説明する。
図３及び図４は、前記装置例によるコンテンツ配信要求の処理例を示すシーケンス図である。
【００７０】
ここで、図３は、マルチコネクション接続装置２において現時点で配信していない未配信中のライブコンテンツに対して、初めてクライアント５が配信要求をした場合の処理例を示している。このように未配信中のライブコンテンツに対して１番目に配信要求した最初のクライアント５を「第１クライアント」という。
【００７１】
図４は、未配信中のライブコンテンツに対して、二人目のクライアントが配信要求をした場合、即ち図３の続きの処理例を示している。このように未配信中のライブコンテンツに対して２番目に配信要求したクライアント５を「第２クライアント」という。
【００７２】
図５、図６及び図７は、メッセージキャッシュ部２３に存在するメッセージキャッシュテーブルの状態を示す図である。
ここで、図５は、図３のシーケンスにおけるＳＴ１まで終了した時のメッセージキャッシュテーブルの状態を示している。図６は、図３のシーケンスにおけるＳＴ７まで終了した時のメッセージキャッシュテーブルの状態を示している。図７は、図３のシーケンス全体が終了した時、即ち第１クライアントの配信要求についての処理が終了した時のメッセージキャッシュテーブルの状態を示している。
【００７３】
図８は、メッセージキャッシュ部２３に存在するメッセージキャッシュ書き換えテーブルの状態を示す図である。
メッセージキャッシュ書き換えテーブルとは、メッセージキャッシュ部２３にキャッシュされるメッセージ（「応答」）についての一部の情報を書き換えて、その一部だけ書き換えられたメッセージを、複数のクライアント５に再利用するときに用いられるテーブルである。図に示すように、メッセージキャッシュ書き換えテーブルには、各メッセージ毎に、「書き換え項目」と「書き換え内容」が格納される。
【００７４】
次に、本方法例２に係るコンテンツ配信要求の処理例を具体的に説明する。
＜最初のクライアントが配信要求する場合＞
【００７５】
図３に示すように、第１クライアントは、コンテンツの配信要求をするために、先ず、クライアント固有情報伝達メッセージMsgAをマルチコネクション接続装置２に対して送信する。ここで、クライアント固有情報伝達メッセージとは、コンテンツの配信要求をした第１クライアントについての認証、第１クライアントのプロフィール、第１クライアントに対する課金又はストリーム放送についての統計など、について用いられるクライアント固有情報からなるものである。即ち、クライアント固有情報伝達メッセージは、各クライアント５に固有の情報であってストリームサーバ１で集中的に処理及び管理すべき情報からなるメッセージである。
【００７６】
マルチコネクション接続装置２は、クライアント固有情報伝達メッセージMsgAを受信すると、そのクライアント固有情報伝達メッセージMsgAをメッセージキャッシュ部２３内のメッセージキャッシュテーブル（図５参照）における「キャッシュＡ」に格納する。なお、メッセージキャッシュテーブルにおける「キャッシュ」欄にある”未”とは、まだキャッシュにメッセージが格納されていない状態、即ち、メッセージがまだキャッシュされていない状態を示している。
【００７７】
そして、図５のメッセージキャッシュテーブルにおける「メッセージ」MsgAに対する「処理」は”スルー”であるので、このスルー処理をマルチコネクション接続装置２が実行する。具体的には、マルチコネクション接続装置２は、第１クライアントから受信したクライアント固有情報伝達メッセージMsgAを、そのままストリームサーバ１に転送する（ＳＴ１）。
【００７８】
ストリームサーバ１は、クライアント固有情報伝達メッセージMsgAをすると、そのクライアント固有情報伝達メッセージMsgAについての処理を行なう。具体的には、このメッセージの送信元の第１クライアントについての認証や課金処理あるいは統計処理などを行なう。その後、ストリームサーバ１は、クライアント固有情報伝達メッセージMsgAについての返答であるResponseMsgAをマルチコネクション接続装置２に送信する。
【００７９】
図５のメッセージキャッシュテーブルにおける「メッセージ」ResponseMsgAに対する「処理」は”スルー”であるので、マルチコネクション接続装置２はResponseMsgAを第１クライアントに転送する。ここで、メッセージキャッシュテーブルにおける「メッセージ」ResponseMsgAに対する「キャッシュ」は”不要”であり、”不要”は受信したメッセージをキャッシュしなくてよいことを示しているので、ResponseMsgAはキャッシュされない（ＳＴ２）。
【００８０】
第１クライアントは、ResponseMsgAを受信した後、コンテンツ要求メッセージMsgBをマルチコネクション接続装置２に対して送信する。ここで、コンテンツ要求メッセージMsgBとは、クライアント５が配信を求めるコンテンツを特定するメッセージとする。
【００８１】
マルチコネクション接続装置２は、コンテンツ要求メッセージMsgBを受信すると、メッセージキャッシュテーブル（図５参照）を検索して、コンテンツ要求メッセージMsgBを、「キャッシュＢ」に格納したうえで、そのコンテンツ要求メッセージMsgBについての終端処理を実行する。終端処理とは、クライアント５から受信したメッセージをストリームサーバ１に上げずに、マルチコネクション接続装置２自身で処理することをいう。
【００８２】
終端処理でコンテンツ要求メッセージMsgBを解析した結果、例えば、第１クライアントが未配信中のライブコンテンツを要求していることがわかる（ＳＴ３）。
【００８３】
そこで、マルチコネクション接続装置２は、未配信中のライブコンテンツの代理要求をストリームサーバ１に対して行なう。この代理要求は、上述の方法例１で説明した代表配信要求として実行する。
【００８４】
具体的には、まず、マルチコネクション接続装置２は、メッセージキャッシュテーブルにキャッシュされているキャッシュＡを用いて、ストリームサーバ１に対して未配信中のライブコンテンツの代理要求を行なう。これにより、キャッシュＡの内容であるメッセージMsgAがマルチコネクション接続装置２からストリームサーバ２へ送信される。
【００８５】
ただし、この代理要求で送信されるメッセージMsgAは、図８に示すメッセージキャッシュ書き換えテーブルに基づいて一部書き換えられて、メッセージMsgA’とされて送信される。具体的には、メッセージMsgAの送信元を示すユーザＩＤがマルチコネクション接続装置２のユーザＩＤに書き換えられる（ＳＴ４）。
【００８６】
ストリームサーバ１は、メッセージMsgA’を受信すると、マルチコネクション接続装置２についての認証処理や統計処理などを行なった後、マルチコネクション接続装置２に対してResponseMsgAを送信する（ＳＴ５）。
【００８７】
マルチコネクション接続装置２は、ResponseMsgAを受信すると、メッセージキャッシュテーブル（図６参照）にキャッシュされているキャッシュＢを用いて、コンテンツ要求メッセージMsgBを、代表配信要求としてストリームサーバ１に送信する。
【００８８】
ただし、この代理要求で送信されるコンテンツ要求メッセージMsgBは、図８に示すメッセージキャッシュ書き換えテーブルに基づいて一部書き換えられて、コンテンツ要求メッセージMsgB’とされて送信される。具体的には、ポート番号がマルチコネクション接続装置２のポート番号に書き換えられる（ＳＴ６）。
【００８９】
ストリームサーバ１は、コンテンツ要求メッセージMsgB’を受信すると、マルチコネクション接続装置２に対して、ResponseMsgBを送信する。マルチコネクション接続装置２は、ResponseMsgBを受信すると、これをメッセージキャッシュテーブル（図６参照）の「キャッシュＣ」に格納し、ResponseMsgBについての終端処理を実行する（ＳＴ７）。
【００９０】
図６には、ＳＴ７までシーケンスが進んだ時のメッセージキャッシュテーブルの状態が示されている。
【００９１】
ＳＴ７の後、マルチコネクション接続装置２は、メッセージキャッシュテーブルのキャッシュＣを用いて、ResponseMsgBをそのまま第１クライアントに送信する（ＳＴ８）。
【００９２】
第１クライアントは、ResponseMsgBを受信した後、コンテンツ視聴開始要求メッセージMsgCをマルチコネクション接続装置２に対して送信する。ここで、コンテンツ視聴開始要求メッセージMsgCとは、クライアント５がコンテンツ要求メッセージMsgBで要求したコンテンツにつき、配信の開始を求めるメッセージとする。
【００９３】
マルチコネクション接続装置２は、コンテンツ視聴開始要求メッセージMsgCを受信すると、メッセージキャッシュテーブル（図６、図７参照）を検索して、コンテンツ視聴開始要求メッセージMsgCを、「キャッシュＤ」に格納したうえで、そのコンテンツ視聴開始要求メッセージMsgCについての終端処理を実行する。その後、マルチコネクション接続装置２は、「キャッシュＤ」を用いて、コンテンツ視聴開始要求メッセージMsgCをストリームサーバ１に送信する（ＳＴ９）。
【００９４】
ストリームサーバ１は、コンテンツ視聴開始要求メッセージMsgCを受信すると、マルチコネクション接続装置２に対して、ResponseMsgCを送信する。マルチコネクション接続装置２は、ResponseMsgCを受信すると、これをメッセージキャッシュテーブル（図６、図７参照）の「キャッシュＥ」に格納したうえで、そのResponseMsgCを第１クライアントに転送する（ＳＴ１０）。
【００９５】
図７には、ＳＴ１０までシーケンスが進んだ時、即ち最初のクライアントの配信要求についての処理が終了した時、のメッセージキャッシュテーブルの状態が示されている。
【００９６】
これらの処理によって、第１クライアントの要求に係るライブコンテンツのストリームデータが、ストリームサーバ１からマルチコネクション接続装置２に対して送信され、更にマルチコネクション接続装置２から第１クライアントへ送信されるようになる。
【００９７】
＜２番目のクライアントが配信要求する場合＞
図４に示すように、第２クライアントは、コンテンツの配信要求をするために、先ず、クライアント固有情報伝達メッセージMsgAをマルチコネクション接続装置２に対して送信する。
【００９８】
マルチコネクション接続装置２は、クライアント固有情報伝達メッセージMsgAを受信すると、メッセージキャッシュテーブル（図７参照）の「処理」欄に従い、”スルー”処理をすべく、クライアント固有情報伝達メッセージMsgAをストリームサーバ１に転送する（ＳＴ１１）。
【００９９】
ここで、クライアント固有情報伝達メッセージMsgAはすでにメッセージキャッシュテーブルに格納されているので、新たな格納は行なわない。
【０１００】
ストリームサーバ１は、クライアント固有情報伝達メッセージMsgAをすると、そのクライアント固有情報伝達メッセージMsgAについての処理を行なう。即ち、第２クライアントについての認証などを行なう。その後、ストリームサーバ１は、クライアント固有情報伝達メッセージMsgAについての返答であるResponseMsgAをマルチコネクション接続装置２に送信する。
【０１０１】
マルチコネクション接続装置２は、ResponseMsgAを受信すると、メッセージキャッシュテーブルの「処理」欄の”スルー”に従い、そのResponseMsgAを第２クライアントに転送する（ＳＴ１２）。
【０１０２】
第２クライアントは、ResponseMsgAを受信した後、コンテンツ要求メッセージMsgBをマルチコネクション接続装置２に対して送信する。
【０１０３】
マルチコネクション接続装置２は、コンテンツ要求メッセージMsgBを受信すると、メッセージキャッシュテーブル（図７参照）の「処理」欄に従い、コンテンツ要求メッセージMsgBについての終端処理を実行する。
【０１０４】
終端処理でコンテンツ要求メッセージMsgBを解析した結果、例えば、第２クライアントが配信中のライブコンテンツを要求していることがわかる（ＳＴ１３）。
【０１０５】
そこで、マルチコネクション接続装置２は、メッセージキャッシュテーブル（図７参照）を検索し、「キャッシュＣ」に格納されているResponseMsgBを第２クライアントに対して送信する（ＳＴ１４）。
【０１０６】
第２クライアントは、ResponseMsgBを受信した後、コンテンツ視聴開始要求メッセージMsgCをマルチコネクション接続装置２に対して送信する（ＳＴ１５）。
【０１０７】
マルチコネクション接続装置２は、コンテンツ視聴開始要求メッセージMsgCを受信すると、メッセージキャッシュテーブル（図７参照）の「処理」欄の”終端”に従って、コンテンツ視聴開始要求メッセージMsgCについての終端処理を実行する。そして、マルチコネクション接続装置２は、メッセージキャッシュテーブルの「キャッシュＥ」に格納されているResponseMsgCを第１クライアントに送信する（ＳＴ１６）。
【０１０８】
これらの処理によって、第２クライアントから出されたコンテンツ配信要求を、マルチコネクション接続装置２が代理に処理し、第１クライアント及び第２クライアントの要求に係るライブコンテンツのストリームデータが、第１クライアント及び第２クライアントの双方に送信されるようになる。即ち、ストリームサーバ１から送信されたライブコンテンツのストリームデータが、マルチコネクション接続装置２を介して、第１クライアント及び第２クライアントに送信されるようになる。
【０１０９】
これらにより、本方法例２によれば、各クライアント５の配信要求に対応するメッセージ（応答）をメッセージキャッシュテーブルに保持している場合には、そのメッセージをクライアント（例えば、第２クライアント）に送信することができる。
【０１１０】
また、各クライアント５の配信要求に対応するメッセージ（応答）をメッセージキャッシュテーブルに保持していない場合には、そのコンテンツの配信元となるストリームサーバ１に対して、配信要求を代表して送信し、その配信要求に対するストリームサーバ１からのメッセージ（応答）をメッセージキャッシュテーブルに保持して、他の複数のクライアント５に対する応答として用いることができる。
【０１１１】
従って、本方法例２によれば、クライアント５の配信要求についてのトラザクションをキャッシュして、当該キャッシュしたものを用いて、複数のクライアントへ配信要求の応答をすることで、マルチコネクション接続装置２での各クライアント５の配信要求について処理負荷を軽減することができる。
【０１１２】
更にまた、本方法例２によれば、クライアント固有情報などストリームサーバ１に送信すべき情報（メッセージ）は、マルチコネクション接続装置２で終端せずにストリームサーバ１に送信することができる。
【０１１３】
即ち、図７のメッセージキャッシュテーブルに示されているように、クライアント固有情報であるメッセージMsgAは、全てスルー処理されてストリームサーバ１に送信されるが、メッセージMsgB及びメッセージMsgCは、マルチコネクション接続装置２で終端される。従って、図４に示すように、第２クライアントから送信されたメッセージMsgB及びメッセージMsgCは、ストリームサーバ１には送信されない。
【０１１４】
従って、本方法例２によれば、ストリームサーバ１においてクライアント５の配信要求についての負荷を軽減しながら、複数のクライアント５の所望の情報についてストリームサーバ１で集中的に管理することができる。
【０１１５】
（方法例３）
前記装置例に適用する本実施形態の方法例３につき、図面を参照して説明する。
図９は、前記装置例に適用する接続性確認処理を示すシーケンス図である。
この接続性確認処理は、クライアント５とマルチコネクション接続装置２との間の接続性確認をする処理である。
この接続性確認処理は、マルチコネクション接続装置２がストリームサーバ１に応答を聞きに行く必要のないクライアントの要求についての処理の一態様を示すものであり、接続性の確認に限らず、クライアントの他の要求について適用してもよい。
即ち、メッセージキャッシュ部２３に事前に所定の応答を予めキャッシュ（格納）しておき、クライアント５からの要求がそのキャッシュされた所定の応答に該当する場合には、ストリームサーバ１に聞きに行くことなく、そのキャッシュされた所定の応答でクライアント５に応答する処理を行なう。
【０１１６】
具体的には、先ず、第１クライアントは、マルチコネクション接続装置２との接続性を確認するために、接続性確認メッセージMsgDをマルチコネクション接続装置２へ送信する（ＳＴ２１）。
【０１１７】
マルチコネクション接続装置２は、接続性確認メッセージMsgDを受信すると、その接続性確認メッセージMsgDを要求解析部２２で解析し、このメッセージが第１クライアントとマルチコネクション接続装置２間の接続性を確認するためのものであると認識する。すると、マルチコネクション接続装置２は、受信した接続性確認メッセージMsgDをストリームサーバ１へ転送することなく、固定メッセージＦ（ResponseMsgD）を第１クライアントへ送信し、接続性の確認をする（ＳＴ２２）。
【０１１８】
ここで、固定メッセージＦ（ResponseMsgD）は、メッセージキャッシュ部２３で予め格納されているメッセージであり、各クライアント５からきた接続性確認メッセージMsgDの応答として用いられる。
【０１１９】
また、第２クライアントとマルチコネクション接続装置２との間の接続性確認も、上述の第１クライアントの場合（ＳＴ２１、ＳＴ２２）と同様に行なわれる。
【０１２０】
即ち、先ず、第２クライアントは、マルチコネクション接続装置２との接続性を確認するために、接続性確認メッセージMsgDをマルチコネクション接続装置２へ送信する（ＳＴ２３）。
【０１２１】
マルチコネクション接続装置２は、受信した接続性確認メッセージMsgDをストリームサーバ１へ転送することなく、固定メッセージＦ（ResponseMsgD）を第２クライアントへ送信し、接続性の確認をする（ＳＴ２４）。
【０１２２】
これらにより、本方法例３によれば、固定メッセージＦ（ResponseMsgD）を用いることで、クライアント５とマルチコネクション接続装置２間の接続性の確認を、ストリームサーバ１に負荷をかけることなく、マルチコネクション接続装置２の負荷増加も抑えながら、迅速に実行することができる。
【０１２３】
以上、本発明の実施形態を説明したが、本発明は、必ずしも上記した事項に限定されるものではなく、本発明の目的を達し、下記する効果を奏する範囲において、適宜変更実施可能である。
【０１２４】
例えば、上述の実施形態では、図１に示すように、ストリームサーバ１とクライアント５，５１，５２，５３，５ｎとの間に、１つのマルチコネクション接続装置２が配置される態様について説明したが、マルチコネクション接続装置２の下流側にクライアント５，５１，５２，５３，５ｎと下位ストリームサーバが配置され、マルチコネクション接続装置２の上流側に上位ストリームサーバが配置される態様に、適用してもよい。即ち、クライアント５の概念に下位ストリームサーバを含め、ストリームサーバ１の概念に上位ストリームサーバを含めてもよい。
【０１２５】
【発明の効果】
以上説明したように、本発明によれば、ストリーム放送を行う際に、複数のクライアントからの同一のストリーム番組（コンテンツ）についての配信要求を、単一の配信要求として、１本の通信路で、且つ、アプリケーションにおいても１対１として、マルチコネクション接続装置からストリームサーバへ送信することができるので、ストリームサーバにおける接続処理を大幅に低減することができ、多数のクライアントに対する大規模なストリーム配信処理が可能となる。
【０１２６】
また、クライアントの配信要求についてのメッセージ（トラザクション）をキャッシュして、当該キャッシュしたメッセージを用いて、複数のクライアントへ配信要求の応答をするので、マルチコネクション接続装置での各クライアントの配信要求について処理負荷を軽減しながら、ストリームサーバの負荷も軽減し、多数のクライアントに対する大規模なストリーム配信処理が可能となる。
【０１２７】
また、クライアントの各種の配信要求についてのメッセージ（トラザクション）を複数キャッシュして、当該複数のメッセージのなかから所望のメッセージ（例えば、クライアント固有情報）については選択してストリームサーバへ転送することを可能として、クライアントの配信要求についてのストリームサーバの負荷を軽減しながら、クライアント固有情報等の所望の情報についてストリームサーバで集中的に管理することが可能となる。
【図面の簡単な説明】
【図１】本発明の装置例に係るマルチコネクション接続装置を適用したシステムの模式接続図である。
【図２】同上に係るマルチコネクション接続装置の主要部を示すブロック図である。
【図３】本発明の実施形態である方法例２に係る最初のクライアントに対する処理例を示すシーケンス図である。
【図４】同上の方法例２に係る２番目のクライアントに対する処理例を示すシーケンス図である。
【図５】同上の方法例２で用いられるメッセージキャッシュテーブルのＳＴ１までの状態を示す図である。
【図６】同上の方法例２で用いられるメッセージキャッシュテーブルのＳＴ７までの状態を示す図である。
【図７】同上の方法例２で用いられるメッセージキャッシュテーブルのＳＴ１０までの状態を示す図である。
【図８】同上の方法例２で用いられるメッセージキャッシュ書き換えテーブルの状態を示す図である。
【図９】本発明の実施形態である方法例３に係る接続性確認処理を示すシーケンス図である。
【図１０】従来のストリーム配信システムの一例を示す模式接続図である。
【符号の説明】
１…ストリームサーバ
２…マルチコネクション接続装置
３…ＴＣＰコネクション
４、４１、４２、４３、４ｎ…ストリーム配信コネクション
５、５１、５２、５３、５ｎ…クライアント
２０…スプリッタ
２１…クライアント側送受信手段
２２…要求解析部
２３…メッセージキャッシュ部
２４…サーバ側送受信手段
３０…ＴＣＰコネクション
【発明の属する技術分野】
本発明は、音声・映像等を含むストリーム放送を、インターネットを介して大規模に配信するのに好適な、マルチコネクション接続装置及びマルチコネクション接続制御方法に関するものである。
【０００２】
【従来の技術】
近年、家庭にあるパーソナル・コンピュータ端末（以下、単に「クライアント」という）とインターネットを利用したストリーミング放送が普及し始めている。
【０００３】
このストリーミング放送は、既存のテレビ放送と比較して映像品質が悪く、現段階では広範囲に普及しているとは言えないが、将来的に、中継回線及び加入者回線の広帯域化に伴い、高品質の映像の配信が可能となって、現在のテレビ放送に匹敵する視聴メディアになるものと予想されている。
【０００４】
現行のストリーミング放送は、既存のテレビ放送における配信形態とは大きく異なり、インターネットに接続されている全ての端末に向けて放送を行う必要はなく、視聴を希望する視聴者の端末にのみ配信される。この結果、ストリーミング放送における配信範囲及び配信数は、各クライアントの受信要求により、放送コンテンツのジャンルや配信時刻（放送時刻）などによって様々に変化する。
【０００５】
ここで、インターネットは、既知のように大部分が有線の地上回線で構成されているが、この地上回線を利用したストリーミング放送の伝送コストは、所要のストリーム番組を、狭範囲に分布する少数の視聴者に向けて配信する場合には減少し、広範囲に分布する多数の視聴者に配信する場合には増大する。
【０００６】
さらに、ストリーミング放送に地上回線を使用する場合、視聴者が急激に増加すると、輻輳に伴う伝搬遅延やパケットロスなどにより、その映像品質が極端に劣化することがある。こうした現状を考慮して、既存の地上回線によるインターネットを利用することなく、各家庭に衛星受信装置を設置し、常にほぼ一定の通信品質が保証された衛星回線を経由して、所要のストリーミング放送を提供するサービスが考え出されている。
【０００７】
図１０は、従来のストリーム配信システムの一例を示す模式接続図である。
従来のストリーム配信システムでは、ストリーム番組の送信元となるストリームサーバ１と、ストリーム番組を受信する複数のクライアント５，５１，５２，５３，５ｎとの間に、中継装置となるスプリッタ２０（プロキシーとも呼ばれる）を配置した構成となっている。
【０００８】
スプリッタ２０としては、Real Net works社のスプリッタ製品が代表的なものとなっている。これは、汎用パソコン又は汎用ワークステーションなどの汎用プロセッサ上で動作し、ストリームサーバ１から受信したストリーム番組（パケット）を、１又は複数のクライアント５，５１，５２，５３，５ｎに対して、コピーして配信するものである。
【０００９】
【発明が解決しようとする課題】
しかしながら、従来のストリーム配信システムにおいては、複数のクライアント５，５１，５２，５３，５ｎからのストリーム配信コネクション４，４１，４２，４３，４ｎを、そのクライアントの数に対応した複数のＴＣＰコネクション３０を用いて、それぞれストリームサーバ１に接続している。なお、ＴＣＰコネクションとは、インターネットで利用される標準プロトコルであるＴＣＰ（Transmission Control Protocol）での接続であり、ＯＳＩ参照モデルのトランスポート層にあたる。また、ストリーム配信コネクション４，４１，４２，４３，４ｎも、それぞれＴＣＰプロトコルによる接続である。
【００１０】
即ち、従来装置のスプリッタ２０は、多数の複数のクライアント５，５１，５２，５３，５ｎそれぞれからストリーム番組の配信要求を受け、その多数の配信要求それぞれを個別にストリームサーバ１に送信している。従って、従来装置のスプリッタ２０では、複数のクライアント５，５１，５２，５３，５ｎが同じストリーム番組についての配信要求をした場合でも、ストリームサーバ１に対して、各クライアント５，５１，５２，５３，５ｎの配信要求ごとにＴＣＰコネクションを行なう接続処理をする必要があった。
【００１１】
これにより、クライアント５の数が増えるほど配信要求についての接続処理が増大するので、多数のクライアント５へストリーム番組を配信する大規模なストリーム放送は、ストリームサーバ１の過負荷となり、且つ、伝送コストも過大となるので、従来のストリーム放送技術では実現が困難であるという問題点があった。換言すれば、従来は、複数のクライアント５からの配信要求ごとにストリームサーバ１に対してコネクション接続処理が必要であったので、ストリームサーバ１の過負荷となり、伝送コストが過大になるという第１の問題点があった。
【００１２】
次に、上述の第１の問題点を解決するために、ストリームサーバ１との接続を行わずに、各クライアント５の配信要求についての処理であるメッセージ処理を終端する（自分で実行する）スプリッタを考えることができる。
【００１３】
しかしながら、このようなメッセージ処理を終端するスプリッタでは、各クライアント５の認証、各クライアント５のプロフィールの取得、ストリーム放送についての統計及びストリーム番組を受信した各クライアント５に対する課金等からなるクライアント固有情報を、収集することができない。
【００１４】
そこで、上述のようなメッセージ処理を終端するスプリッタでは、ストリームサーバ１におけるコネクション接続処理は低減するが、当該スプリッタにおけるメッセージ処理についての負荷が増大し、更に、各クライアント５，５１，５２，５３，５ｎの認証、各クライアント５，５１，５２，５３，５ｎのプロフィールの取得、ストリーム放送についての統計及びストリーム番組を受信した各クライアント５，５１，５２，５３，５ｎに対する課金等について、サービス性が低減する、という第２の問題点がある。
【００１５】
次に、上述の第２の問題点を解決するためには、各クライアント５，５１，５２，５３，５ｎの認証、各クライアント５，５１，５２，５３，５ｎのプロフィールの取得、ストリーム放送についての統計及びストリーム番組を受信した各クライアント５，５１，５２，５３，５ｎに対する課金等の処理を実行するクライアント固有情報処理機能を、スプリッタに付加させることが考えられる。
【００１６】
しかしながら、このようにクライアント固有情報処理機能をスプリッタに付加させると、ストリームサーバ１において集中管理していた機能が分散されてしまう。特に、複数のスプリッタを用いて、大規模なストリーム配信をする場合には、ストリームサーバ１が持っていた機能の分散化が顕著となる。
【００１７】
そこで、クライアント固有情報処理機能をスプリッタに付加させると、各クライアント５，５１，５２，５３，５ｎの認証、各クライアント５，５１，５２，５３，５ｎのプロフィールの取得、ストリーム放送についての統計、ストリーム番組を受信した各クライアント５，５１，５２，５３，５ｎに対する課金、及び各スプリッタの動作等についての管理が複雑になり、クライアント固有情報処理機能等について各スプリッタごとに設定しなければならないのでその設定コストが増大し、クライアント固有情報処理機能等についての処理オーバーヘッドも増大する、という第３の問題点がある。
【００１８】
ここにおいて、本発明の解決すべき主要な目的は以下の通りである。
即ち、本発明の第１の目的は、多数のクライアントにストリーム放送を配信する大規模なストリーム配信処理を可能とするマルチコネクション接続装置及びマルチコネクション接続制御方法を提供せんとするものである。
【００１９】
本発明の第２の目的は、複数のクライアントからの複数のストリーム配信コネクションを、単一のストリーム配信コネクションとしてまとめて、ストリームサーバに接続することで、ストリームサーバの負荷を軽減し、大規模なストリーム配信処理を可能とするマルチコネクション接続装置及びマルチコネクション接続制御方法を提供せんとするものである。
【００２０】
本発明の第３の目的は、クライアントの配信要求についてのトラザクションをキャッシュ（保持）して、当該保持したものを用いて、複数のクライアントへ配信要求の応答をすることで、マルチコネクション接続装置（スプリッタ）での各クライアントの配信要求について処理負荷を軽減することを可能とするマルチコネクション接続装置及びマルチコネクション接続制御方法を提供せんとするものである。
【００２１】
本発明の第４の目的は、クライアントの各種の配信要求についてのトラザクションを複数キャッシュして、当該複数のトラザクションのなかから所望のトラザクションを選択して実施することを可能として、クライアントの配信要求についてのストリームサーバの負荷を軽減しながら、クライアント固有情報等の所望の情報についてストリームサーバで集中的に管理することを可能とするマルチコネクション接続装置及びマルチコネクション接続制御方法を提供せんとするものである。
【００２２】
本発明の他の目的は、明細書、図面、特に、特許請求の範囲における各請求項の記載から自ずと明らかとなろう。
【００２３】
【課題を解決するための手段】
本発明装置は、上記課題の解決に当たり、クライアントから受信したパケットに含まれているストリームコンテンツ要求情報を解析する要求解析部と、要求解析部が解析したストリームコンテンツ要求情報を格納するメッセージキャッシュ部とを、有し、当該メッセージキャッシュ部は、複数のストリームコンテンツ要求情報を、１つのストリームコンテンツ要求情報をなす代表配信要求にまとめて、サーバ側送受信手段からストリームサーバに送信する仕組みからなる構成手段を講じる特徴を有する。
【００２４】
本発明方法は、上記課題の解決に当たり、複数のクライアントのそれぞれからストリームコンテンツの配信要求を受信し、当該複数の配信要求を１つの配信要求をなす代表配信要求として、１つのＴＣＰプロトコルでの接続でストリームサーバに送信する、構成手法を講じる特徴を有する。
【００２５】
更に、具体的詳細に述べると、当該課題の解決では、本発明が次に列挙する上位概念から下位概念にわたる新規な特徴的構成手段又は手法を採用することにより、上記目的を達成するように為される。
【００２６】
即ち、本発明装置の第１の特徴は、複数のクライアントと単一のストリームサーバ間に介在してコネクション接続するために、ストリームサーバに対してパケットの送受信をするサーバ側送受信手段と、複数のクライアントに対してパケットの送受信をするクライアント側送受信手段と、当該クライアント側送受信手段がクライアントから受信したパケットに含まれているストリームコンテンツ要求情報を解析する要求解析部と、当該要求解析部が解析したストリームコンテンツ要求情報と、前記サーバ側送受信手段が前記ストリームサーバから受信したパケットに含まれている前記クライアントの要求に対するメッセージとなる応答と、を格納するとともに、同一のストリームコンテンツに対する複数のストリームコンテンツ要求情報を、１つのストリームコンテンツ要求情報をなす代表配信要求にまとめ、当該代表配信要求を前記サーバ側送受信手段から前記ストリームサーバに送信させる機能構成をなすメッセージキャッシュ部と、を有するマルチコネクション接続装置であって、前記要求解析部は、前記ストリームコンテンツ要求情報が前記クライアントに固有の情報からなるクライアント固有情報を前記メッセージキャッシュ部に格納していないと判断した場合は、当該ストリームコンテンツ要求情報に対応する処理を実行し、当該ストリームコンテンツ要求情報が当該クライアントに固有の情報からなるクライアント固有情報を前記メッセージキャシュ部に格納していると判断した場合は、当該ストリームコンテンツ要求情報を前記サーバ側送受信手段から前記ストリームサーバへ送信させる機能構成を有してなるマルチコネクション接続装置の構成採用にある。
【００２７】
本発明装置の第２の特徴は、上記本発明装置の第１の特徴における前記コネクションが、単一の前記マルチコネクション接続装置と複数の前記クライアント間は当該クライアント数に対応するストリーム配信コネクションであるマルチコネクション接続装置の構成採用にある。
【００２８】
本発明装置の第３の特徴は、上記本発明装置の第１又は第２の特徴における前記コネクションが、単一の前記マルチコネクション接続装置と前記ストリームサーバ間は単一のＴＣＰコネクションであるマルチコネクション接続装置の構成採用にある。
【００２９】
本発明装置の第４の特徴は、上記本発明装置の第１、第２又は第３の特徴における前記要求解析部が、複数のクライアントからそれぞれ送出される前記ストリームコンテンツ要求情報を、各当該クライアント毎の複数のトラザクションとして、前記クライアント側送受信手段を介して、受信する機能構成をなし、前記メッセージキャッシュ部が、当該要求解析部が複数のクライアントから受信した複数のトラザクションにおける同一のストリームコンテンツについての複数のトラザクションを、前記代表配信要求を行なう１個のトラザクションとして、前記サーバ側送受信手段に送信させる機能構成をなしてなるマルチコネクション接続装置の構成採用にある。
【００３０】
本発明装置の第５の特徴は、上記本発明装置の第１、第２、第３又は第４の特徴における前記クライアント側送受信手段が、複数のクライアントのそれぞれとＴＣＰプロトコルで接続してパケットの送受信をする機能構成をなし、前記サーバ側送受信手段が、前記ストリームサーバに対してのＴＣＰプロトコルを用いた単一接続で、前記代表配信要求を送信する機能構成をなしてなるマルチコネクション接続装置の構成採用にある。
【００３１】
本発明装置の第６の特徴は、上記本発明装置の第１、第２、第３、第４又は第５の特徴における前記クライアント側送受信手段が、複数のクライアント及び／又は下位ストリームサーバのそれぞれとＴＣＰプロトコルで接続してパケットの送受信をする機能構成をなし、前記サーバ側送受信手段が、上位ストリームサーバに対してのＴＣＰプロトコルを用いた単一接続で、前記代表配信要求を送信する機能構成をなしてなるマルチコネクション接続装置の構成採用にある。
【００３２】
本発明装置の第７の特徴は、上記本発明装置の第１、第２、第３、第４、第５又は第６の特徴における前記メッセージキャッシュ部が、前記代表配信要求を、１つの送信元ポート番号と１つの宛先ポート番号とを用いて、１つのアプリケーションから他の１つのアプリケーションに引き渡されるデータとして、前記サーバ側送受信手段から前記ストリームサーバへ送信させる機能構成をなしてなるマルチコネクション接続装置の構成採用にある。
【００３３】
本発明装置の第８の特徴は、上記本発明装置の第１の特徴における前記要求解析部で判断される前記クライアント固有情報が、前記配信要求をしたクライアントの認証、当該クライアントのプロフィール、当該クライアントに対する課金及びストリーム放送についての統計、の内の少なくとも１つについて用いられる情報からなるマルチコネクション接続装置の構成採用にある。
【００３４】
本発明装置の第９の特徴は、上記本発明装置の第１の特徴における前記メッセージキャッシュ部には、前記クライアントの要求に対する、前記ストリームサーバから受信したパケットが格納されており、前記要求解析部は、前記クライアントから受信したパケットに含まれている要求が、前記クライアント情報を格納しておらず、当該メッセージキャッシュ部に予め格納されている当該所定の応答又は、ストリームコンテンツに該当する前記ストリームコンテンツ要求情報であると判断した場合は、前記ストリームサーバに聞きにいくことなく、当該所定の応答を当該クライアントに向けて送信させる、機能構成を有してなるマルチコネクション接続装置の構成採用にある。
【００３８】
本発明方法の第１の特徴は、複数のクライアントと単一のストリームサーバ間にマルチコネクション接続手段を介接したコネクション接続を制御するために、複数のクライアントのそれぞれとＴＣＰプロトコルで接続して、当該複数のクライアントのそれぞれからストリームコンテンツの配信要求を受信し、当該配信要求に対応する応答を保持している場合には、当該応答を当該クライアントに送信するとともに、当該配信要求に対応する応答を保持していない場合には、当該ストリームコンテンツの配信元となるストリームサーバに対して、単一のコネクションで接続して、当該配信要求を代表して送信し、当該配信要求に対するストリームサーバからの応答を保持し、当該応答を、当該配信要求した複数のクライアントに送信するのに先立って、前記クライアントの配信要求が当該クライアントに固有の情報からなるクライアント固有情報を前記マルチコネクション接続手段内に格納していないと判断された場合は、当該配信要求に対応する処理を当該マルチコネクション接続手段内で実行する終端処理を行うとともに、前記クライアントの配信要求が当該クライアントに固有の情報からなるクライアント固有情報を前記マルチコネクション接続手段内に格納していると判断された場合は、当該配信要求を前記ストリームサーバに送信するスルー処理を行なってなるマルチコネクション接続制御方法の構成採用にある。
【００３９】
本発明方法の第２の特徴は、上記本発明方法の第１の特徴における前記クライアント固有情報が、前記配信要求をしたクライアントの認証、当該クライアントのプロフィール、当該クライアントに対する課金及びストリーム放送についての統計、の内の少なくとも１つについて用いられる情報からなるマルチコネクション接続制御方法の構成採用にある。
【００４０】
本発明方法の第３の特徴は、上記本発明方法の第１又は第２の特徴における前記マルチコネクション接続制御方法が、前記クライアントから出された要求が、当該クライアントと前記マルチコネクション接続手段間の接続性を確認するものである場合は、当該マルチコネクション接続手段において事前に保持されている応答を、当該マルチコネクション接続手段が当該クライアントに送信してなるマルチコネクション接続制御方法の構成採用にある。
【００４６】
【発明の実施の形態】
以下、添付図面を参照しながら、本発明の実施の形態を装置例及び方法例につき説明する。
【００４７】
なお、本発明は、複数のクライアントからの要求にかかる複数のストリーム配信コネクションを、単一のストリーム配信コネクションとしてストリームサーバに接続することで、ストリームサーバにおける接続処理についての負荷を低減することに関する発明であるが、本実施形態では、インターネットを介してストリーム番組を配信する形態を挙げて説明するも、本発明はこれ等に限定されるものではなく、インターネット以外の各種の通信網にも適用できる。
【００４８】
（装置例）
図１は、本発明の装置例を示すマルチコネクション接続装置を適用したシステムの接続形態を示す模式図である。
図中、１はストリーム番組をなすパケット（以下、「ストリームパケット」という。）の送信元となるストリームサーバ、２は本発明の装置例であるマルチコネクション接続装置、５，５１，５２，５３，５ｎはストリームパケットを受信する複数のクライアントである。
【００４９】
ここで、ストリームサーバ１とマルチコネクション接続装置２は、ＴＣＰコネクション３で接続される。ＴＣＰコネクション３は、ＴＣＰプロトコルによる接続である。マルチコネクション接続装置２と各クライアント５，５１，５２，５３，５ｎとは、それぞれストリーム配信コネクション４，４１，４２，４３，４ｎで接続される。ストリーム配信コネクション４，４１，４２，４３，４ｎのそれぞれも、ＴＣＰプロトコルによる接続である。
【００５０】
従って、マルチコネクション接続装置２は、複数のクライアント５，５１，５２，５３，５ｎからの複数のストリーム配信コネクション４，４１，４２，４３，４ｎを、その接続数を低減して、ＴＣＰコネクション３として、ストリームサーバ１に接続するものである。
【００５１】
図２は、本発明の装置例であるマルチコネクション接続装置２の主要部を示す概念ブロック図である。
マルチコネクション接続装置２の主要部は、クライアント側送受信手段２１と、要求解析部２２と、メッセージキャッシュ部２３と、サーバ側送受信手段２４とで構成されている。
【００５２】
クライアント側送受信手段２１は、複数のクライアント５，５１，５２，５３，５ｎそれぞれ対して、ＴＣＰプロトコルで接続して、パケットの送受信をするものである。サーバ側送受信手段２４は、ストリームサーバ１に対して、ＴＣＰプロトコルで接続して、パケットの送受信をするものである。
【００５３】
要求解析部２２は、クライアント側送受信手段２１がクライアント５，５１，５２，５３，５ｎから受信したパケットに含まれているストリームコンテンツ要求情報を解析するものである。ここで、要求解析部２２は、複数のクライアント５，５１，５２，５３，５ｎからそれぞれ送出されるストリームコンテンツ要求情報を、各クライアント毎の複数のトラザクションとして、クライアント側送受信手段２１を介して、受信するものである。
【００５４】
メッセージキャッシュ部２３は、要求解析部２２が解析したストリームコンテンツ要求情報を格納するものである。また、メッセージキャッシュ部２３は、同一のストリームコンテンツに対する複数のストリームコンテンツ要求情報を、１つのストリームコンテンツ要求情報をなす代表配信要求にまとめ、当該代表配信要求をサーバ側送受信手段２４からストリームサーバ１に送信させる、ものである。
【００５５】
即ち、メッセージキャッシュ部２３は、要求解析部２２が行なった複数のクライアント５，５１，５２，５３，５ｎについての複数の接続処理（トラザクション）における同一のストリームコンテンツについての複数のトラザクションを、代表配信要求を行なう１個のトラザクションとして、サーバ側送受信手段２４とストリームサーバ１との間で実行させるものである。これにより、サーバ側送受信手段２４は、ストリームサーバ１に対してのＴＣＰプロトコルを用いた１つの接続で、代表配信要求を送信する。
【００５６】
これらにより、マルチコネクション接続装置２は、同一のストリームコンテンツに対して配信要求を行う複数のストリームコンテンツ要求情報を１つのストリームコンテンツ要求情報をなす代表配信要求にまとめて、サーバ側送受信手段２４からストリームサーバ１に送信することができる。従って、ストリームサーバ１において、クライアント５，５１，５２，５３，５ｎからストリームコンテンツ要求についての接続処理（トラザクション）を大幅に低減することができるので、多数のクライアントにストリーム放送を配信する大規模なストリーム配信処理を実現することができる。
【００５７】
メッセージキャッシュ部２３の具体的構成としては、代表配信要求を、１つの送信元ポート番号（マルチコネクション２内の１個のアプリケーションを指すポート番号）と１つの宛先ポート番号（ストリームサーバ１内の１個のアプリケーションを指すポート番号）とを用いて、１つのアプリケーションから他の１つのアプリケーションに引き渡されるデータとして、サーバ側送受信手段２４からストリームサーバ１へ送信させるものとする。
【００５８】
即ち、マルチコネクション接続装置２内の１個のアプリケーションから、ストリームサーバ１内の１個のアプリケーションへ引き渡すデータとして、送信させる。
【００５９】
また、メッセージキャッシュ部２３は、要求解析部２２が解析したストリームコンテンツ要求情報のみならず、サーバ側送受信手段２４がストリームサーバ１から受信したパケットに含まれているものであってクライアント５の要求に対するメッセージとなる「応答」をも、格納するものである。
【００６０】
そして、要求解析部２２は、クライアント５から送られてきたストリームコンテンツ要求情報に対応する「応答」が、メッセージキャッシュ部２３に格納されているか判断する機能を持つ。要求解析部２２は、当該「応答」が格納されていると判断した場合は、当該「応答」をクライアント側送受信手段２１からクライアント５へ送信させる機能も持つ。
【００６１】
要求解析部２２は、当該「応答」がメッセージキャッシュ部２３に格納されていないと判断した場合は、要求されたストリームコンテンツの配信元となるストリームサーバ１に対して、代表配信要求を送信させる機能も持つ。
【００６２】
ここで、当該「応答」とは、クライアント５のストリームコンテンツの要求に対する回答などとなるメッセージであって、ストリームサーバ１からサーバ側送受信手段２４が受信してメッセージキャッシュ部２３に格納されたものである。
【００６３】
これらにより、マルチコネクション接続装置２は、クライアント５の各種のストリームコンテンツ要求に対するトラザクションを「応答」としてメッセージキャッシュ部２３にキャッシュしておき、キャッシュした応答を、複数のクライアント５のストリームコンテンツ要求に用いることができるので、マルチコネクション接続装置２での各クライアント５の配信要求に対する応答メッセージの送信についての処理負荷を軽減することができる。
【００６４】
（方法例１）
前記装置例に適用する本実施形態の方法例１につき、図面を参照して説明する。
【００６５】
先ず、クライアント５，５１，５２，５３，５ｎのそれぞれからストリームコンテンツの配信要求があった場合に、クライアント側送受信手段２１が複数のクライアント５，５１，５２，５３，５ｎのそれぞれとＴＣＰプロトコルで接続して、複数のクライアント５，５１，５２，５３，５ｎのそれぞれからストリームコンテンツの配信要求を受信する。
【００６６】
その後、複数の配信要求を要求解析部２２が解析する。この解析結果に基づいて、メッセージキャッシュ部２３が同一のストリームコンテンツに対する複数の配信要求を、１つの配信要求をなす代表配信要求にまとめる。
その後、サーバ側送受信手段２４がストリームコンテンツの配信元となるストリームサーバ１に対して、１つのトラザクションとしてＴＣＰプロトコルで接続し、代表配信要求を送信する。
【００６７】
ここで、代表配信要求は、１つの送信元ポート番号と、１つの宛先ポート番号とが特定されて、マルチコネクション接続装置２内の１つのアプリケーションから、ストリームサーバ１内の１つのアプリケーションに、引き渡されるデータとして、ストリームサーバ１に送信される。
【００６８】
これらにより、マルチコネクション接続装置２は、ストリームサーバ１との間において、複数のクライアント５，５１，５２，５３，５ｎからの複数のストリームコンテンツの配信要求について、１本の通信路（ＴＣＰコネクション３）で、且つ、アプリケーションにおいても１対１として、処理することができ、ストリームサーバ１の接続処理（トラザクション）を大幅に低減することができる。
【００６９】
（方法例２）
前記装置例に適用する本実施形態の方法例２につき、図面を参照して説明する。
図３及び図４は、前記装置例によるコンテンツ配信要求の処理例を示すシーケンス図である。
【００７０】
ここで、図３は、マルチコネクション接続装置２において現時点で配信していない未配信中のライブコンテンツに対して、初めてクライアント５が配信要求をした場合の処理例を示している。このように未配信中のライブコンテンツに対して１番目に配信要求した最初のクライアント５を「第１クライアント」という。
【００７１】
図４は、未配信中のライブコンテンツに対して、二人目のクライアントが配信要求をした場合、即ち図３の続きの処理例を示している。このように未配信中のライブコンテンツに対して２番目に配信要求したクライアント５を「第２クライアント」という。
【００７２】
図５、図６及び図７は、メッセージキャッシュ部２３に存在するメッセージキャッシュテーブルの状態を示す図である。
ここで、図５は、図３のシーケンスにおけるＳＴ１まで終了した時のメッセージキャッシュテーブルの状態を示している。図６は、図３のシーケンスにおけるＳＴ７まで終了した時のメッセージキャッシュテーブルの状態を示している。図７は、図３のシーケンス全体が終了した時、即ち第１クライアントの配信要求についての処理が終了した時のメッセージキャッシュテーブルの状態を示している。
【００７３】
図８は、メッセージキャッシュ部２３に存在するメッセージキャッシュ書き換えテーブルの状態を示す図である。
メッセージキャッシュ書き換えテーブルとは、メッセージキャッシュ部２３にキャッシュされるメッセージ（「応答」）についての一部の情報を書き換えて、その一部だけ書き換えられたメッセージを、複数のクライアント５に再利用するときに用いられるテーブルである。図に示すように、メッセージキャッシュ書き換えテーブルには、各メッセージ毎に、「書き換え項目」と「書き換え内容」が格納される。
【００７４】
次に、本方法例２に係るコンテンツ配信要求の処理例を具体的に説明する。
＜最初のクライアントが配信要求する場合＞
【００７５】
図３に示すように、第１クライアントは、コンテンツの配信要求をするために、先ず、クライアント固有情報伝達メッセージMsgAをマルチコネクション接続装置２に対して送信する。ここで、クライアント固有情報伝達メッセージとは、コンテンツの配信要求をした第１クライアントについての認証、第１クライアントのプロフィール、第１クライアントに対する課金又はストリーム放送についての統計など、について用いられるクライアント固有情報からなるものである。即ち、クライアント固有情報伝達メッセージは、各クライアント５に固有の情報であってストリームサーバ１で集中的に処理及び管理すべき情報からなるメッセージである。
【００７６】
マルチコネクション接続装置２は、クライアント固有情報伝達メッセージMsgAを受信すると、そのクライアント固有情報伝達メッセージMsgAをメッセージキャッシュ部２３内のメッセージキャッシュテーブル（図５参照）における「キャッシュＡ」に格納する。なお、メッセージキャッシュテーブルにおける「キャッシュ」欄にある”未”とは、まだキャッシュにメッセージが格納されていない状態、即ち、メッセージがまだキャッシュされていない状態を示している。
【００７７】
そして、図５のメッセージキャッシュテーブルにおける「メッセージ」MsgAに対する「処理」は”スルー”であるので、このスルー処理をマルチコネクション接続装置２が実行する。具体的には、マルチコネクション接続装置２は、第１クライアントから受信したクライアント固有情報伝達メッセージMsgAを、そのままストリームサーバ１に転送する（ＳＴ１）。
【００７８】
ストリームサーバ１は、クライアント固有情報伝達メッセージMsgAをすると、そのクライアント固有情報伝達メッセージMsgAについての処理を行なう。具体的には、このメッセージの送信元の第１クライアントについての認証や課金処理あるいは統計処理などを行なう。その後、ストリームサーバ１は、クライアント固有情報伝達メッセージMsgAについての返答であるResponseMsgAをマルチコネクション接続装置２に送信する。
【００７９】
図５のメッセージキャッシュテーブルにおける「メッセージ」ResponseMsgAに対する「処理」は”スルー”であるので、マルチコネクション接続装置２はResponseMsgAを第１クライアントに転送する。ここで、メッセージキャッシュテーブルにおける「メッセージ」ResponseMsgAに対する「キャッシュ」は”不要”であり、”不要”は受信したメッセージをキャッシュしなくてよいことを示しているので、ResponseMsgAはキャッシュされない（ＳＴ２）。
【００８０】
第１クライアントは、ResponseMsgAを受信した後、コンテンツ要求メッセージMsgBをマルチコネクション接続装置２に対して送信する。ここで、コンテンツ要求メッセージMsgBとは、クライアント５が配信を求めるコンテンツを特定するメッセージとする。
【００８１】
マルチコネクション接続装置２は、コンテンツ要求メッセージMsgBを受信すると、メッセージキャッシュテーブル（図５参照）を検索して、コンテンツ要求メッセージMsgBを、「キャッシュＢ」に格納したうえで、そのコンテンツ要求メッセージMsgBについての終端処理を実行する。終端処理とは、クライアント５から受信したメッセージをストリームサーバ１に上げずに、マルチコネクション接続装置２自身で処理することをいう。
【００８２】
終端処理でコンテンツ要求メッセージMsgBを解析した結果、例えば、第１クライアントが未配信中のライブコンテンツを要求していることがわかる（ＳＴ３）。
【００８３】
そこで、マルチコネクション接続装置２は、未配信中のライブコンテンツの代理要求をストリームサーバ１に対して行なう。この代理要求は、上述の方法例１で説明した代表配信要求として実行する。
【００８４】
具体的には、まず、マルチコネクション接続装置２は、メッセージキャッシュテーブルにキャッシュされているキャッシュＡを用いて、ストリームサーバ１に対して未配信中のライブコンテンツの代理要求を行なう。これにより、キャッシュＡの内容であるメッセージMsgAがマルチコネクション接続装置２からストリームサーバ２へ送信される。
【００８５】
ただし、この代理要求で送信されるメッセージMsgAは、図８に示すメッセージキャッシュ書き換えテーブルに基づいて一部書き換えられて、メッセージMsgA’とされて送信される。具体的には、メッセージMsgAの送信元を示すユーザＩＤがマルチコネクション接続装置２のユーザＩＤに書き換えられる（ＳＴ４）。
【００８６】
ストリームサーバ１は、メッセージMsgA’を受信すると、マルチコネクション接続装置２についての認証処理や統計処理などを行なった後、マルチコネクション接続装置２に対してResponseMsgAを送信する（ＳＴ５）。
【００８７】
マルチコネクション接続装置２は、ResponseMsgAを受信すると、メッセージキャッシュテーブル（図６参照）にキャッシュされているキャッシュＢを用いて、コンテンツ要求メッセージMsgBを、代表配信要求としてストリームサーバ１に送信する。
【００８８】
ただし、この代理要求で送信されるコンテンツ要求メッセージMsgBは、図８に示すメッセージキャッシュ書き換えテーブルに基づいて一部書き換えられて、コンテンツ要求メッセージMsgB’とされて送信される。具体的には、ポート番号がマルチコネクション接続装置２のポート番号に書き換えられる（ＳＴ６）。
【００８９】
ストリームサーバ１は、コンテンツ要求メッセージMsgB’を受信すると、マルチコネクション接続装置２に対して、ResponseMsgBを送信する。マルチコネクション接続装置２は、ResponseMsgBを受信すると、これをメッセージキャッシュテーブル（図６参照）の「キャッシュＣ」に格納し、ResponseMsgBについての終端処理を実行する（ＳＴ７）。
【００９０】
図６には、ＳＴ７までシーケンスが進んだ時のメッセージキャッシュテーブルの状態が示されている。
【００９１】
ＳＴ７の後、マルチコネクション接続装置２は、メッセージキャッシュテーブルのキャッシュＣを用いて、ResponseMsgBをそのまま第１クライアントに送信する（ＳＴ８）。
【００９２】
第１クライアントは、ResponseMsgBを受信した後、コンテンツ視聴開始要求メッセージMsgCをマルチコネクション接続装置２に対して送信する。ここで、コンテンツ視聴開始要求メッセージMsgCとは、クライアント５がコンテンツ要求メッセージMsgBで要求したコンテンツにつき、配信の開始を求めるメッセージとする。
【００９３】
マルチコネクション接続装置２は、コンテンツ視聴開始要求メッセージMsgCを受信すると、メッセージキャッシュテーブル（図６、図７参照）を検索して、コンテンツ視聴開始要求メッセージMsgCを、「キャッシュＤ」に格納したうえで、そのコンテンツ視聴開始要求メッセージMsgCについての終端処理を実行する。その後、マルチコネクション接続装置２は、「キャッシュＤ」を用いて、コンテンツ視聴開始要求メッセージMsgCをストリームサーバ１に送信する（ＳＴ９）。
【００９４】
ストリームサーバ１は、コンテンツ視聴開始要求メッセージMsgCを受信すると、マルチコネクション接続装置２に対して、ResponseMsgCを送信する。マルチコネクション接続装置２は、ResponseMsgCを受信すると、これをメッセージキャッシュテーブル（図６、図７参照）の「キャッシュＥ」に格納したうえで、そのResponseMsgCを第１クライアントに転送する（ＳＴ１０）。
【００９５】
図７には、ＳＴ１０までシーケンスが進んだ時、即ち最初のクライアントの配信要求についての処理が終了した時、のメッセージキャッシュテーブルの状態が示されている。
【００９６】
これらの処理によって、第１クライアントの要求に係るライブコンテンツのストリームデータが、ストリームサーバ１からマルチコネクション接続装置２に対して送信され、更にマルチコネクション接続装置２から第１クライアントへ送信されるようになる。
【００９７】
＜２番目のクライアントが配信要求する場合＞
図４に示すように、第２クライアントは、コンテンツの配信要求をするために、先ず、クライアント固有情報伝達メッセージMsgAをマルチコネクション接続装置２に対して送信する。
【００９８】
マルチコネクション接続装置２は、クライアント固有情報伝達メッセージMsgAを受信すると、メッセージキャッシュテーブル（図７参照）の「処理」欄に従い、”スルー”処理をすべく、クライアント固有情報伝達メッセージMsgAをストリームサーバ１に転送する（ＳＴ１１）。
【００９９】
ここで、クライアント固有情報伝達メッセージMsgAはすでにメッセージキャッシュテーブルに格納されているので、新たな格納は行なわない。
【０１００】
ストリームサーバ１は、クライアント固有情報伝達メッセージMsgAをすると、そのクライアント固有情報伝達メッセージMsgAについての処理を行なう。即ち、第２クライアントについての認証などを行なう。その後、ストリームサーバ１は、クライアント固有情報伝達メッセージMsgAについての返答であるResponseMsgAをマルチコネクション接続装置２に送信する。
【０１０１】
マルチコネクション接続装置２は、ResponseMsgAを受信すると、メッセージキャッシュテーブルの「処理」欄の”スルー”に従い、そのResponseMsgAを第２クライアントに転送する（ＳＴ１２）。
【０１０２】
第２クライアントは、ResponseMsgAを受信した後、コンテンツ要求メッセージMsgBをマルチコネクション接続装置２に対して送信する。
【０１０３】
マルチコネクション接続装置２は、コンテンツ要求メッセージMsgBを受信すると、メッセージキャッシュテーブル（図７参照）の「処理」欄に従い、コンテンツ要求メッセージMsgBについての終端処理を実行する。
【０１０４】
終端処理でコンテンツ要求メッセージMsgBを解析した結果、例えば、第２クライアントが配信中のライブコンテンツを要求していることがわかる（ＳＴ１３）。
【０１０５】
そこで、マルチコネクション接続装置２は、メッセージキャッシュテーブル（図７参照）を検索し、「キャッシュＣ」に格納されているResponseMsgBを第２クライアントに対して送信する（ＳＴ１４）。
【０１０６】
第２クライアントは、ResponseMsgBを受信した後、コンテンツ視聴開始要求メッセージMsgCをマルチコネクション接続装置２に対して送信する（ＳＴ１５）。
【０１０７】
マルチコネクション接続装置２は、コンテンツ視聴開始要求メッセージMsgCを受信すると、メッセージキャッシュテーブル（図７参照）の「処理」欄の”終端”に従って、コンテンツ視聴開始要求メッセージMsgCについての終端処理を実行する。そして、マルチコネクション接続装置２は、メッセージキャッシュテーブルの「キャッシュＥ」に格納されているResponseMsgCを第１クライアントに送信する（ＳＴ１６）。
【０１０８】
これらの処理によって、第２クライアントから出されたコンテンツ配信要求を、マルチコネクション接続装置２が代理に処理し、第１クライアント及び第２クライアントの要求に係るライブコンテンツのストリームデータが、第１クライアント及び第２クライアントの双方に送信されるようになる。即ち、ストリームサーバ１から送信されたライブコンテンツのストリームデータが、マルチコネクション接続装置２を介して、第１クライアント及び第２クライアントに送信されるようになる。
【０１０９】
これらにより、本方法例２によれば、各クライアント５の配信要求に対応するメッセージ（応答）をメッセージキャッシュテーブルに保持している場合には、そのメッセージをクライアント（例えば、第２クライアント）に送信することができる。
【０１１０】
また、各クライアント５の配信要求に対応するメッセージ（応答）をメッセージキャッシュテーブルに保持していない場合には、そのコンテンツの配信元となるストリームサーバ１に対して、配信要求を代表して送信し、その配信要求に対するストリームサーバ１からのメッセージ（応答）をメッセージキャッシュテーブルに保持して、他の複数のクライアント５に対する応答として用いることができる。
【０１１１】
従って、本方法例２によれば、クライアント５の配信要求についてのトラザクションをキャッシュして、当該キャッシュしたものを用いて、複数のクライアントへ配信要求の応答をすることで、マルチコネクション接続装置２での各クライアント５の配信要求について処理負荷を軽減することができる。
【０１１２】
更にまた、本方法例２によれば、クライアント固有情報などストリームサーバ１に送信すべき情報（メッセージ）は、マルチコネクション接続装置２で終端せずにストリームサーバ１に送信することができる。
【０１１３】
即ち、図７のメッセージキャッシュテーブルに示されているように、クライアント固有情報であるメッセージMsgAは、全てスルー処理されてストリームサーバ１に送信されるが、メッセージMsgB及びメッセージMsgCは、マルチコネクション接続装置２で終端される。従って、図４に示すように、第２クライアントから送信されたメッセージMsgB及びメッセージMsgCは、ストリームサーバ１には送信されない。
【０１１４】
従って、本方法例２によれば、ストリームサーバ１においてクライアント５の配信要求についての負荷を軽減しながら、複数のクライアント５の所望の情報についてストリームサーバ１で集中的に管理することができる。
【０１１５】
（方法例３）
前記装置例に適用する本実施形態の方法例３につき、図面を参照して説明する。
図９は、前記装置例に適用する接続性確認処理を示すシーケンス図である。
この接続性確認処理は、クライアント５とマルチコネクション接続装置２との間の接続性確認をする処理である。
この接続性確認処理は、マルチコネクション接続装置２がストリームサーバ１に応答を聞きに行く必要のないクライアントの要求についての処理の一態様を示すものであり、接続性の確認に限らず、クライアントの他の要求について適用してもよい。
即ち、メッセージキャッシュ部２３に事前に所定の応答を予めキャッシュ（格納）しておき、クライアント５からの要求がそのキャッシュされた所定の応答に該当する場合には、ストリームサーバ１に聞きに行くことなく、そのキャッシュされた所定の応答でクライアント５に応答する処理を行なう。
【０１１６】
具体的には、先ず、第１クライアントは、マルチコネクション接続装置２との接続性を確認するために、接続性確認メッセージMsgDをマルチコネクション接続装置２へ送信する（ＳＴ２１）。
【０１１７】
マルチコネクション接続装置２は、接続性確認メッセージMsgDを受信すると、その接続性確認メッセージMsgDを要求解析部２２で解析し、このメッセージが第１クライアントとマルチコネクション接続装置２間の接続性を確認するためのものであると認識する。すると、マルチコネクション接続装置２は、受信した接続性確認メッセージMsgDをストリームサーバ１へ転送することなく、固定メッセージＦ（ResponseMsgD）を第１クライアントへ送信し、接続性の確認をする（ＳＴ２２）。
【０１１８】
ここで、固定メッセージＦ（ResponseMsgD）は、メッセージキャッシュ部２３で予め格納されているメッセージであり、各クライアント５からきた接続性確認メッセージMsgDの応答として用いられる。
【０１１９】
また、第２クライアントとマルチコネクション接続装置２との間の接続性確認も、上述の第１クライアントの場合（ＳＴ２１、ＳＴ２２）と同様に行なわれる。
【０１２０】
即ち、先ず、第２クライアントは、マルチコネクション接続装置２との接続性を確認するために、接続性確認メッセージMsgDをマルチコネクション接続装置２へ送信する（ＳＴ２３）。
【０１２１】
マルチコネクション接続装置２は、受信した接続性確認メッセージMsgDをストリームサーバ１へ転送することなく、固定メッセージＦ（ResponseMsgD）を第２クライアントへ送信し、接続性の確認をする（ＳＴ２４）。
【０１２２】
これらにより、本方法例３によれば、固定メッセージＦ（ResponseMsgD）を用いることで、クライアント５とマルチコネクション接続装置２間の接続性の確認を、ストリームサーバ１に負荷をかけることなく、マルチコネクション接続装置２の負荷増加も抑えながら、迅速に実行することができる。
【０１２３】
以上、本発明の実施形態を説明したが、本発明は、必ずしも上記した事項に限定されるものではなく、本発明の目的を達し、下記する効果を奏する範囲において、適宜変更実施可能である。
【０１２４】
例えば、上述の実施形態では、図１に示すように、ストリームサーバ１とクライアント５，５１，５２，５３，５ｎとの間に、１つのマルチコネクション接続装置２が配置される態様について説明したが、マルチコネクション接続装置２の下流側にクライアント５，５１，５２，５３，５ｎと下位ストリームサーバが配置され、マルチコネクション接続装置２の上流側に上位ストリームサーバが配置される態様に、適用してもよい。即ち、クライアント５の概念に下位ストリームサーバを含め、ストリームサーバ１の概念に上位ストリームサーバを含めてもよい。
【０１２５】
【発明の効果】
以上説明したように、本発明によれば、ストリーム放送を行う際に、複数のクライアントからの同一のストリーム番組（コンテンツ）についての配信要求を、単一の配信要求として、１本の通信路で、且つ、アプリケーションにおいても１対１として、マルチコネクション接続装置からストリームサーバへ送信することができるので、ストリームサーバにおける接続処理を大幅に低減することができ、多数のクライアントに対する大規模なストリーム配信処理が可能となる。
【０１２６】
また、クライアントの配信要求についてのメッセージ（トラザクション）をキャッシュして、当該キャッシュしたメッセージを用いて、複数のクライアントへ配信要求の応答をするので、マルチコネクション接続装置での各クライアントの配信要求について処理負荷を軽減しながら、ストリームサーバの負荷も軽減し、多数のクライアントに対する大規模なストリーム配信処理が可能となる。
【０１２７】
また、クライアントの各種の配信要求についてのメッセージ（トラザクション）を複数キャッシュして、当該複数のメッセージのなかから所望のメッセージ（例えば、クライアント固有情報）については選択してストリームサーバへ転送することを可能として、クライアントの配信要求についてのストリームサーバの負荷を軽減しながら、クライアント固有情報等の所望の情報についてストリームサーバで集中的に管理することが可能となる。
【図面の簡単な説明】
【図１】本発明の装置例に係るマルチコネクション接続装置を適用したシステムの模式接続図である。
【図２】同上に係るマルチコネクション接続装置の主要部を示すブロック図である。
【図３】本発明の実施形態である方法例２に係る最初のクライアントに対する処理例を示すシーケンス図である。
【図４】同上の方法例２に係る２番目のクライアントに対する処理例を示すシーケンス図である。
【図５】同上の方法例２で用いられるメッセージキャッシュテーブルのＳＴ１までの状態を示す図である。
【図６】同上の方法例２で用いられるメッセージキャッシュテーブルのＳＴ７までの状態を示す図である。
【図７】同上の方法例２で用いられるメッセージキャッシュテーブルのＳＴ１０までの状態を示す図である。
【図８】同上の方法例２で用いられるメッセージキャッシュ書き換えテーブルの状態を示す図である。
【図９】本発明の実施形態である方法例３に係る接続性確認処理を示すシーケンス図である。
【図１０】従来のストリーム配信システムの一例を示す模式接続図である。
【符号の説明】
１…ストリームサーバ
２…マルチコネクション接続装置
３…ＴＣＰコネクション
４、４１、４２、４３、４ｎ…ストリーム配信コネクション
５、５１、５２、５３、５ｎ…クライアント
２０…スプリッタ
２１…クライアント側送受信手段
２２…要求解析部
２３…メッセージキャッシュ部
２４…サーバ側送受信手段
３０…ＴＣＰコネクション
Claims (12)
- 複数のクライアントと単一のストリームサーバ間に介在してコネクション接続するために、
ストリームサーバに対してパケットの送受信をするサーバ側送受信手段と、
複数のクライアントに対してパケットの送受信をするクライアント側送受信手段と、
当該クライアント側送受信手段がクライアントから受信したパケットに含まれているストリームコンテンツ要求情報を解析する要求解析部と、
当該要求解析部が解析したストリームコンテンツ要求情報と、前記サーバ側送受信手段が前記ストリームサーバから受信したパケットに含まれている前記クライアントの要求に対するメッセージとなる応答と、を格納するとともに、同一のストリームコンテンツに対する複数のストリームコンテンツ要求情報を、１つのストリームコンテンツ要求情報をなす代表配信要求にまとめ、当該代表配信要求を前記サーバ側送受信手段から前記ストリームサーバに送信させる機能構成をなすメッセージキャッシュ部と、を有するマルチコネクション接続装置であって、
前記要求解析部は、
前記ストリームコンテンツ要求情報が前記クライアントに固有の情報からなるクライアント固有情報を前記メッセージキャッシュ部に格納していないと判断した場合は、当該ストリームコンテンツ要求情報に対応する処理を実行し、当該ストリームコンテンツ要求情報が当該クライアントに固有の情報からなるクライアント固有情報を前記メッセージキャシュ部に格納していると判断した場合は、当該ストリームコンテンツ要求情報を前記サーバ側送受信手段から前記ストリームサーバへ送信させる機能構成を有する、
ことを特徴とするマルチコネクション接続装置。 - 前記コネクションは、
単一の前記マルチコネクション接続装置と複数の前記クライアント間は当該クライアント数に対応するストリーム配信コネクションである、
ことを特徴とする請求項１に記載のマルチコネクション接続装置。 - 前記コネクションは、
単一の前記マルチコネクション接続装置と前記ストリームサーバ間は単一のＴＣＰコネクションである、
ことを特徴とする請求項１又は２に記載のマルチコネクション接続装置。 - 前記要求解析部は、
複数のクライアントからそれぞれ送出される前記ストリームコンテンツ要求情報を、各当該クライアント毎の複数のトラザクションとして、前記クライアント側送受信手段を介して、受信する機能構成をなし、
前記メッセージキャッシュ部は、
当該要求解析部が複数のクライアントから受信した複数のトラザクションにおける同一のストリームコンテンツについての複数のトラザクションを、前記代表配信要求を行なう１個のトラザクションとして、前記サーバ側送受信手段に送信させる機能構成をなす、
ことを特徴とする請求項１、２又は３に記載のマルチコネクション接続装置。 - 前記クライアント側送受信手段は、
複数のクライアントのそれぞれとＴＣＰプロトコルで接続してパケットの送受信をする機能構成をなし、
前記サーバ側送受信手段は、前記ストリームサーバに対してのＴＣＰプロトコルを用いた単一接続で、前記代表配信要求を送信する機能構成をなす、
ことを特徴とする請求項１、２、３又は４に記載のマルチコネクション接続装置。 - 前記クライアント側送受信手段は、
複数のクライアント及び／又は下位ストリームサーバのそれぞれとＴＣＰプロトコルで接続してパケットの送受信をする機能構成をなし、
前記サーバ側送受信手段は、上位ストリームサーバに対してのＴＣＰプロトコルを用いた単一接続で、前記代表配信要求を送信する機能構成をなす、
ことを特徴とする請求項１、２、３、４又は５に記載のマルチコネクション接続装置。 - 前記メッセージキャッシュ部は、
前記代表配信要求を、１つの送信元ポート番号と１つの宛先ポート番号とを用いて、１つのアプリケーションから他の１つのアプリケーションに引き渡されるデータとして、前記サーバ側送受信手段から前記ストリームサーバへ送信させる機能構成をなす、
ことを特徴とする請求項１、２、３、４、５又は６に記載のマルチコネクション接続装置。 - 前記要求解析部で判断される前記クライアント固有情報は、
前記配信要求をしたクライアントの認証、当該クライアントのプロフィール、当該クライアントに対する課金及びストリーム放送についての統計、の内の少なくとも１つについて用いられる情報からなる、
ことを特徴とする請求項１に記載のマルチコネクション接続装置。 - 前記メッセージキャッシュ部には、
前記クライアントの要求に対する、前記ストリームサーバから受信したパケットが格納されており、
前記要求解析部は、
前記クライアントから受信したパケットに含まれている要求が、前記クライアント情報を格納しておらず、当該メッセージキャッシュ部に予め格納されている当該所定の応答又は、ストリームコンテンツに該当する前記ストリームコンテンツ要求情報であると判断した場合は、前記ストリームサーバに聞きにいくことなく、当該所定の応答を当該クライアントに向けて送信させる、機能構成を有する、
ことを特徴とする請求項１に記載のマルチコネクション接続装置。 - 複数のクライアントと単一のストリームサーバ間にマルチコネクション接続手段を介接したコネクション接続を制御するために、
複数のクライアントのそれぞれとＴＣＰプロトコルで接続して、当該複数のクライアントのそれぞれからストリームコンテンツの配信要求を受信し、
当該配信要求に対応する応答を保持している場合には、当該応答を当該クライアントに送信するとともに、当該配信要求に対応する応答を保持していない場合には、当該ストリームコンテンツの配信元となるストリームサーバに対して、単一のコネクションで接続して、当該配信要求を代表して送信し、当該配信要求に対するストリームサーバからの応答を保持し、当該応答を、当該配信要求した複数のクライアントに送信するのに先立って、
前記クライアントの配信要求が当該クライアントに固有の情報からなるクライアント固有情報を前記マルチコネクション接続手段内に格納していないと判断された場合は、当該配信要求に対応する処理を当該マルチコネクション接続手段内で実行する終端処理を行うとともに、前記クライアントの配信要求が当該クライアントに固有の情報からなるクライアント固有情報を前記マルチコネクション接続手段内に格納していると判断された場合は、当該配信要求を前記ストリームサーバに送信するスルー処理を行なう、
ことを特徴とするマルチコネクション接続制御方法。 - 前記クライアント固有情報は、
前記配信要求をしたクライアントの認証、当該クライアントのプロフィール、当該クライアントに対する課金及びストリーム放送についての統計、の内の少なくとも１つについて用いられる情報からなる、
ことを特徴とする請求項１０に記載のマルチコネクション接続制御方法。 - 前記マルチコネクション接続制御方法は、
前記クライアントから出された要求が、当該クライアントと前記マルチコネクション接続手段間の接続性を確認するものである場合は、当該マルチコネクション接続手段において事前に保持されている応答を、当該マルチコネクション接続手段が当該クライアントに送信する、
ことを特徴とする請求項１０又は１１に記載のマルチコネクション接続制御方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001084708A JP3685729B2 (ja) | 2001-03-23 | 2001-03-23 | マルチコネクション接続装置及びマルチコネクション接続制御方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001084708A JP3685729B2 (ja) | 2001-03-23 | 2001-03-23 | マルチコネクション接続装置及びマルチコネクション接続制御方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2002290457A JP2002290457A (ja) | 2002-10-04 |
| JP3685729B2 true JP3685729B2 (ja) | 2005-08-24 |
Family
ID=18940338
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001084708A Expired - Lifetime JP3685729B2 (ja) | 2001-03-23 | 2001-03-23 | マルチコネクション接続装置及びマルチコネクション接続制御方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3685729B2 (ja) |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH1023005A (ja) * | 1996-07-05 | 1998-01-23 | Nippon Telegr & Teleph Corp <Ntt> | マルチキャスト配信方法及びシステム |
| JP3644155B2 (ja) * | 1996-11-08 | 2005-04-27 | 株式会社明電舎 | Ｉｓｄｎターミナルサーバのデータ処理方法 |
| JPH11112541A (ja) * | 1997-09-12 | 1999-04-23 | Internatl Business Mach Corp <Ibm> | メッセージ中継方法及びメッセージ処理方法、ルータ装置、ネットワークシステム、ルータ装置を制御するプログラムを格納した記憶媒体 |
| JPH11313059A (ja) * | 1998-04-27 | 1999-11-09 | Nippon Telegr & Teleph Corp <Ntt> | マルチキャスト通信方法及びそのシステム並びにマルチキャスト通信プログラムを記録した記録媒体 |
| JP3558977B2 (ja) * | 2000-10-05 | 2004-08-25 | 日本電信電話株式会社 | ストリーム中継装置およびストリーム放送配信ネットワークおよび記録媒体 |
| JP2002259267A (ja) * | 2001-03-01 | 2002-09-13 | Matsushita Electric Ind Co Ltd | 動画配信方法および動画配信装置およびそのプログラム記録媒体 |
-
2001
- 2001-03-23 JP JP2001084708A patent/JP3685729B2/ja not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| JP2002290457A (ja) | 2002-10-04 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10321199B2 (en) | Streaming with optional broadcast delivery of data segments | |
| US8935313B2 (en) | Quick session setup for video on demand with information caching | |
| CN104246737B (zh) | 在内容分发网络中使用视频流的连接池技术的系统和方法 | |
| CA2553458A1 (en) | Network architecture for data transmission | |
| CN1328868C (zh) | 在分布式对等流媒体服务系统中实现可靠组播的方法 | |
| US20110246608A1 (en) | System, method and device for delivering streaming media | |
| US20010029525A1 (en) | Method of utilizing a single uniform resource locator for resources with multiple formats | |
| US20100198977A1 (en) | Automatic live stream trees | |
| JP2001521716A (ja) | マルチキャスト・ネットワークにおいてマルチキャスト・グループ・メンバシップを管理するためのシステム，デバイスおよび方法 | |
| US20200021859A1 (en) | Multicast implementation method and related network device | |
| WO2008025294A1 (fr) | Système, dispositif et procédé par connexion pair à pair de flux multimedia | |
| US20040181575A1 (en) | Method and apparatus for providing peer-to-peer push using broadcast query | |
| WO2009082041A1 (en) | Group communication system using media server having distributed structure and method thereof | |
| JP5001880B2 (ja) | ストリーミングサービスのシステムと方法 | |
| JP2015510301A (ja) | 複数の通信リンクを結合するシステム及び方法 | |
| US9083538B2 (en) | Methods and apparatus for creation and transport of multimedia content flows to a distribution network | |
| CN102227893A (zh) | 用于建立数字媒体流的方法和系统 | |
| JP3685729B2 (ja) | マルチコネクション接続装置及びマルチコネクション接続制御方法 | |
| US20060174025A1 (en) | System and method for streaming content utilizing client upstream communication bandwidth capacity over a network | |
| US20020065918A1 (en) | Method and apparatus for efficient and accountable distribution of streaming media content to multiple destination servers in a data packet network (DPN) | |
| US20100309913A1 (en) | Method and system for handling iptv multicast traffic in a home network | |
| CN112788135B (zh) | 资源调度方法、设备及存储介质 | |
| CN102640515A (zh) | 节目内容获取方法及机顶盒 | |
| CN111556324B (zh) | 一种视频直播的方法、装置、设备及系统 | |
| CN113840151A (zh) | Ott组播网关调度方法、装置和系统、存储介质 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20040412 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20041005 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20041202 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20050531 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20050531 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 3685729 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090610 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090610 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100610 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100610 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110610 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120610 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130610 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140610 Year of fee payment: 9 |
|
| S531 | Written request for registration of change of domicile |
Free format text: JAPANESE INTERMEDIATE CODE: R313531 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| EXPY | Cancellation because of completion of term |