JP2002335283A - 同報通信方法およびシステム - Google Patents

Abstract

(57)【要約】 【課題】 コネクション数を増やさずに、グループ内の
限定されたメンバにだけ選択的にデータ転送するなどの
柔軟な同報通信を実現すること。 【解決手段】 同報通信データを送信する送信側端末
と、同報通信データを受信する複数の受信側端末とを備
え、送信画側端末から１ないし複数の受信側端末を指定
して同報通信データをマルチキャストプロトコルで送信
する同報通信方法において、前記送信側端末から送信す
る同報通信データの先頭に受信側端末を指定するパラメ
ータを付加して送信するステップと、それぞれの受信側
端末において、送信側端末から受信した同報通信データ
の先頭に付加されたパラメータを解析し、当該同報通信
データを受信するか廃棄するかを決定するステップとを
備える。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、先生端末と生徒端
末がパソコンなどの端末を利用して授業を支援する教育
支援システムなどのように、１対多の端末相互間で通信
を行うシステムにおいてデータ通信の信頼性や柔軟性を
向上させることに貢献する同報通信方法およびシステム
に関するものである。

【０００２】

【従来の技術】例えば、先生端末と生徒端末がパソコン
などの端末を利用して授業を支援する教育支援システム
などのように、１台の先生端末と複数台の生徒端末との
間でデータ通信する場合、すべての生徒端末は同一のデ
ータを先生端末から受信し、その受信データを自分が使
用する生徒端末のスクリーンに描画することが多い。こ
の時、先生端末と生徒端末間のセッションを生徒端末毎
に確立する方法では、同一のデータを転送する場合も生
徒端末の台数分のパケットを先生端末から転送する必要
があり、トラフィック増大の原因となる。

【０００３】これに対して、同報通信のプロトコルで
は、先生端末から送信されるパケットを複数の生徒端末
が共有することができるため、リアルタイムアプリケー
ションのデータ通信への適用が可能である。ここで、端
末間でリアルタイム性が要求される画面を共有して授業
を進める際の同報通信を行うことを考えた場合、通信の
信頼性を確保する仕組みとして、３ＷＡＹハンドシェイ
クを利用するTCP/IPプロトコルを適用する方法が想定さ
れる。しかし、このTCP/IPプロトコルでは、通信プロト
コル処理によるオーバヘッドや応答確認のための複数回
通信が必要になり、スループットの低下を招くという問
題が発生する。また、TCP/IPプロトコルをマルチメディ
ア通信のような大容量かつリアルタイム性が要求される
データ通信を提供するシステムに適用する場合、転送遅
延の問題がネックとなり、ネットワークのスループット
の向上を妨げることになる。これに対して、ブロードキ
ャストやマルチキャストを利用した同報通信方式では、
プロトコルレベルでの応答確認を実行しないUDP/IP（UD
P:User Datagram Protocol）での通信を実行するため、
プロトコル処理によるオーバヘッドが軽減できる利点が
あり、リアルタイム性が要求される高速データ通信に適
している。

【０００４】

【発明が解決しようとする課題】しかしながら、UDP/IP
プロトコルではデータ通信の信頼性が保証されないた
め、データ転送オーバランによるネットワークの輻輳や
パケットロスなどの障害を回避することができない。す
なわち、同報通信を性能面から考慮した場合、マルチキ
ャストのような信頼性のないプロトコルで不用意にパケ
ットの転送間隔を短くしてしまうと、オーバランによる
パケットロスが発生してしまう。これを回避するため
に、パケットの転送間隔を調節するのだが、必ずパケッ
トロスを「０」にできるわけではない。

【０００５】また、同報通信を信頼性の面から考慮した
場合、応答確認を実行する手段がない。同報通信の上位
で応答確認の機能を追加する場合にも、データを送信し
た端末だけではなく、すべての端末に応答を返すことし
かできない。このアーキテクチャでは、ある端末が複数
の端末に同一のデータを送信する場合には、１つのパケ
ットを複数の端末で共有するという同報通信の利点を活
用することができるが、複数の端末が１台の端末に応答
確認パケットを送信する場合には、それぞれの端末ごと
に応答確認パケットが送信されるため、結局、同報通信
の利点を活用できなくなる。

【０００６】また、同報通信を柔軟性の面から考慮した
場合、グループに属するメンバ全員にデータを送信する
ことはできるが、グループ中の特定のメンバにだけデー
タを送信することができない。この場合、端末ごとにコ
ネクションを張るユニキャストのような接続方式では、
データを送信するメンバを柔軟に選択することができる
が、複数のメンバにデータを送信する場合、メンバ数と
同一のパケットを送信しなくてはならず、ネットワーク
トラフィックを増大させてしまう。ここで、データ転送
時の性能を向上させる方法としては、ＡＴＭ（非同期転
送モード）を利用する方法が考えられる。ＡＴＭではハ
ードウェアレベルでのフロー制御がなされるため、通信
プロトコル処理のオーバヘッドが軽減されるが、現在の
LAN/Ethernetのアーキテクチャが主流になっているシス
テムにおいては、ＡＴＭへの移行はコスト面などから考
慮しても最善の解決策とは言えない。すなわち、現在の
システムを流用しつつ、いかにマルチメディアデータ通
信に適したソフトウェア的な解決を行うかが重要である
が、ＡＴＭでは解決できない。

【０００７】また、マルチキャストプロトコルに高信頼
性を確保する方法として、RMTP（Reliable Multicast T
ransfer Protocol）が存在するが、マルチキャストプロ
トコルの上位で信頼性を確保するための冗長な制御機構
を保持しており、TCP/IPと同様、プロトコル処理のオー
バヘッドにより性能が劣化する問題が発生する。また、
同報通信時の柔軟性を向上する方法としてデータ転送を
中継して振り分ける方法が考えられるが、中継機器を考
慮することで、システムの汎用性が失われてしまうとい
う新たな問題が発生する。

【０００８】本発明は、このような問題を解決するため
になされたものであり、その第１の目的は、コネクショ
ン数を増やさずに、グループ内の限定されたメンバにだ
け選択的にデータ転送するなどの柔軟な同報通信を実現
できる同報通信方法およびシステムを提供することにあ
る。第２の目的は、データ転送レートを向上させた場合
に発生するパケットロスの増大を抑制し、同報通信デー
タのスループットを向上させることができる同報通信方
法およびシステムを提供することにある。第３の目的
は、データ転送フロー制御を端末内で稼動するリアルタ
イムアプリケーションが直接実行することにより、リア
ルタイムアプリケーション実行時の品質の向上を図り、
ネットワークの状態に依存しないシームレスな描画表示
を行うことができる同報通信方法およびシステムを提供
することにある。第４の目的は、同報通信のＴＴＬ(Tim
e To Live)の設定を動的に変更することで同報通信の応
答パケットが送信される範囲を隣接ノードの端末だけに
限定できることを利用し、ネットワークのトラフィック
削減することができる同報通信方法およびシステムを提
供することにある。

【０００９】

【課題を解決するための手段】上記目的を達成するため
に、本発明の同報通信方法は、同報通信データを送信す
る送信側端末と、同報通信データを受信する複数の受信
側端末とを備え、送信画側端末から１ないし複数の受信
側端末を指定して同報通信データをマルチキャストプロ
トコルで送信する同報通信方法において、前記送信側端
末から送信する同報通信データの先頭に受信側端末を指
定するパラメータを付加して送信するステップと、それ
ぞれの受信側端末において、送信側端末から受信した同
報通信データの先頭に付加されたパラメータを解析し、
当該同報通信データを受信するか廃棄するかを決定する
ステップとを備えることを特徴とする。また、前記送信
側端末の表示画面情報をウインドウ単位またはアイコン
単位で分類し、その分類結果をオブジェクトに変換し、
オブジェクト単位で受信側端末に送信するステップを備
えることを特徴とする。また、同一のセグメント上に存
在している受信側端末のプロセッサスケジューリングを
制御し、受信側端末からの送信データを一時的に停止
し、送信側端末から送信されるデータの転送レートの限
界値を一定時間に限り上昇させるステップを備えること
を特徴とする。また、送信側端末が同報通信データを送
信している間、受信側端末のコンテキストスイッチの切
り替えを禁止し、受信側端末のＣＰＵをネットワークイ
ンタフェース中のバッファ領域を開放する処理に割り当
てるステップを備えることを特徴とする。また、受信側
端末においてネットワークインタフェースバッファ中の
受信側端末を示すパラメータの領域に直接アクセスし、
ネットワークインタフェースバッファ中の同報通信デー
タをカーネルバッファにコピーせずに、受信したパケッ
トが必要なパケットか否かを判断するステップを備える
ことを特徴とする。また、送信側端末及び受信側端末に
おけるネットワークインタフェースとアプリケーション
の中間に設けたバッファリング層においてアプリケーシ
ョンデータをバッファリングするステップを備えること
を特徴とする。また、送信側端末及び受信側端末におけ
るアプリケーションへのデータ受信通知のインターバル
を変更するステップを備えることを特徴とする。また、
送信側端末において同報通信データの他にパケットの優
先度テーブルを送信するステップと、受信側端末におい
て受信した優先度テーブルに基づき動的にサービス品質
を変更するステップを備えることを特徴とする。また、
送信側端末に対する確認応答または再送要求を自受信側
端末に近いノードの他の受信側端末に送信するステップ
を備えることを特徴とする。

【００１０】本発明に係る同報通信システムは、同報通
信データを送信する送信側端末と、同報通信データを受
信する複数の受信側端末とを備え、送信画側端末から１
ないし複数の受信側端末を指定して同報通信データをマ
ルチキャストプロトコルで送信する同報通信システムに
おいて、前記送信側端末が、送信する同報通信データの
先頭に受信側端末を指定するパラメータを付加して送信
する手段を備え、それぞれの受信側端末が、送信側端末
から受信した同報通信データの先頭に付加されたパラメ
ータを解析し、当該同報通信データを受信するか廃棄す
るかを決定する手段を備えることを特徴とする。また、
前記送信側端末が、自端末の表示画面情報をウインドウ
単位またはアイコン単位で分類し、その分類結果をオブ
ジェクトに変換し、オブジェクト単位で受信側端末に送
信する手段を備えることを特徴とする。また、送信側端
末が、同一のセグメント上に存在している受信側端末の
プロセッサスケジューリングを制御し、受信側端末から
の送信データを一時的に停止し、送信側端末から送信さ
れるデータの転送レートの限界値を一定時間に限り上昇
させる手段を備えることを特徴とする。また、受信側端
末が、同報通信データを受信している間、受信側端末の
コンテキストスイッチの切り替えを禁止し、受信側端末
のＣＰＵをネットワークインタフェース中のバッファ領
域を開放する処理に割り当てる手段を備えることを特徴
とする。また、受信側端末が、ネットワークインタフェ
ースバッファ中の受信側端末を示すパラメータの領域に
直接アクセスし、ネットワークインタフェースバッファ
中の同報通信データをカーネルバッファにコピーせず
に、受信したパケットが必要なパケットか否かを判断す
る手段を備えることを特徴とする。また、送信側端末及
び受信側端末が、ネットワークインタフェースとアプリ
ケーションの中間に設けたバッファリング層においてア
プリケーションデータをバッファリングする手段を備え
ることを特徴とする。また、送信側端末及び受信側端末
が、アプリケーションへのデータ受信通知のインターバ
ルを変更する手段を備えることを特徴とする。また、送
信側端末が同報通信データの他にパケットの優先度テー
ブルを送信する手段を備え、受信側端末が、受信した優
先度テーブルに基づき動的にサービス品質を変更する手
段を備えることを特徴とする。また、受信側端末が、送
信側端末に対する確認応答または再送要求を自受信側端
末に近いノードの他の受信側端末に送信する手段を備え
ることを特徴とする。

【００１１】

【発明の実施の形態】以下、本発明の実施の形態を、図
面を用いて詳細に説明する。図１は、本発明の一実施形
態を示すシステム構成図である。この実施形態は、１つ
の先生端末と複数の生徒端末とから成る教育支援システ
ムに本発明を適用したものである。図１に示すシステム
は、同報通信を用いるため、ネットワーク１０１上に、
マルチキャスト対応ルータ（１）１０２、マルチキャス
ト対応ルータ（２）１０３が複数配置され、それぞれの
マルチキャスト対応ルータにつながるサブネットワーク
（１）１０４、サブネットワーク（２）１０５が存在す
る。これらのサブネットワーク（１）１０４には、端末
（１１）１０４Ａ、端末（１２）１０４Ｂ、…、端末
（１ｎ）１０４Ｃが、サブネットワーク２には端末（２
１）１０５Ａ、端末（２２）１０５Ｂ、…、端末（２
ｎ）１０５Ｃが接続されている。これらの端末１０４Ａ
〜１０５Ｃは、生徒端末に相当する。また、ネットワー
ク１０１には、先生端末に相当する端末１０６が接続さ
れている。

【００１２】図２は、各端末１０４Ａ〜１０５Ｃおよび
１０６の内部構成の例を示すブロック構成図である。以
下、生徒端末１０４Ａ〜１０５Ｃについては１つの生徒
端末を代表して生徒端末１０４と言う。各生徒端末１０
４、１０５および先生端末１０６は、ユーザ管理プログ
ラム１１Ａ、画面共有プログラム１１Ｂからなる教育シ
ステムプログラム１１とを備え、さらに、アプリケーシ
ョンインタフェース１２、同報通信拡張プログラム１３
Ａ、タスク管理プログラム１３Ｂ、キャッシュバッファ
１３Ｃ、共有バッファ１３Ｄ、端末ＣＰＵ１３Ｅからな
るオペレーティングシステムカーネル１３と、ネットワ
ークインタフェースバッファ１４Ａ、ネットワークイン
タフェースＣＰＵ１４Ｂ、ネットワークインタフェース
１４Ｃからなるネットワークインタフェースカード１４
とを備えている。

【００１３】本発明の目的は前述の通りであるが、具体
的には次の通りになる。 （１）１つのグループへのデータ転送で、データを受信
する端末を選択できるようにする。 （２）リアルタイムアプリケーションの転送データ量を
削減する。 （３）ＯＳのコンテキストスイッチ時間を軽減する。 （４）デバイスドライバ内バッファからアプリケーショ
ン領域へのデータコピー時間を軽減する。 （５）通信プロトコル処理のオーバヘッドを回避する。 （６）輻輳ウインドウ制御などでフローアルゴリズムで
利用されている、直感的な使用帯域見積を訂正し、厳密
に帯域の見積を実現する。 （７）端末内でアプリケーションへの転送レートを制御
し、シームレスな画面表示を提供する。 （８）データ受信の応答確認のパケットがグループ全体
に送信されるのを回避する。

【００１４】そこで、本実施形態のシステムでは、先生
端末１０６が複数の生徒端末１０４、１０５を選択して
個別指導を実行する機能を実現するために、先生端末１
０６が生徒端末１０４、１０５のグループに送信した送
信データがどの生徒端末１０４、１０５に必要かどうか
の判断を生徒端末側で判断する。なお、複数の生徒端末
からなる１つの生徒端末グループに同じデータを送信す
る場合は、生徒端末グループに一意なＩＤを割り当て、
データの先頭にパラメータとして挿入すると、対象とな
る生徒端末グループではパラメータを参照して自分宛の
データであることを判断できる。また、対象外の生徒端
末では、自分宛のデータではないことを判断できるた
め、パケットを廃棄する。

【００１５】ユーザ管理プログラム１１Ａでは、生徒端
末１０４、１０５がユーザ管理テーブル（図３で後述）
を利用して、送信されたデータが必要なデータか必要で
ないデータかの判断を行うことができるように、グルー
プに参加している生徒端末１０４、１０５を把握し、ユ
ーザ管理テーブル（図３）の作成、生徒端末へユーザ管
理テーブルを送信する機能を保持する。先生端末１０６
上で稼動する画面共有プログラム１１Ｂは、先生端末１
０６の画面を生徒端末１０４とで共有するために、一定
の間隔で画面データを取得し、生徒端末１０４に送信す
る機能が設けられている。また、生徒端末１０４上で稼
動する画面共有プログラム１１Ｂでは、先生端末１０６
から送信された画面データを表示させる機能が設けられ
ている。

【００１６】また本システムでは、１回の画面データの
データ転送量を削減するため、画面共有プログラム１１
Ｂは、画面データをウインドウ単位に切り分け、画面情
報を保持したオブジェクトに変換してデータを転送する
機能が設けられている。各オブジェクトはウインドウテ
ーブル（図５で後述）上で管理され、状態や座標に変更
がある度に、ウインドウテーブルが書き換えられる。同
報通信拡張プログラム１３Ａは、先生端末１０６と生徒
端末１０４間のデータ転送の性能、信頼性、柔軟性向上
を目的として、データ転送のプロトコルレベルでの制御
を実現する。グループ内の生徒端末１０４を一意に特定
するMember IDを保持し、Member IDを利用してネットワ
ークインタフェースバッファ１４Ａにデータがある状態
で、必要なデータか必要でないデータかを判断すること
で、バッファコピーのオーバヘッドを回避する。

【００１７】高レートデータ転送時には、タスク管理プ
ログラム１３Ｂにコンテキストスイッチの禁止を要求
し、ネットワークインタフェースバッファ１４Ａの処理
だけを実行する。データを受信した生徒端末１０４は近
隣ノードの端末だけにＡＣＫ(応答確認)を送信し、グル
ープ全体にＡＣＫが送信されることによる冗長なトラフ
ィックの増大を回避する。データの再送要求に関しても
同様に、データを正しく受信した生徒端末１０４の情報
を共有することで、グループ全体にデータ再送要求を送
信するのではなく、一番近いノードに対して再送を要求
する。タスク管理プログラム１３Ｂは、高レートデータ
転送時にネットワークインタフェースバッファが溢れて
パケットロスが発生するのを回避するために、ＯＳのコ
ンテキストスイッチの切替を制御する機能を備えてい
る。

【００１８】図３（ａ）は、先生端末１０６内のユーザ
管理プログラム１１Ａが作成するユーザ管理テーブル３
００の構成を示した図である。ユーザ管理テーブル３０
０は、Member項目３０１、Member ID項目３０２、Dista
nce項目３０３、Node ID項目３０４、Max Node項目３０
５を保持するようになっている。生徒端末１０４が新規
にグループに参加した場合、先生端末１０６に対し「He
lloパケット」を送信する。先生端末１０６は生徒端末
１０４からの「Helloパケット」を受信すると、その端
末のアドレス(socket名)をMember項目３０１に格納し、
また生徒端末１０４に一意なMember IDを割り当て、そ
の割り当てたMemberIDをMember ID項目３０２に格納す
る。さらに、先生端末１０６と生徒端末１０４との間の
ネットワーク距離をDistance項目３０３に格納し、また
生徒端末１０４が存在するNodeごとに一意に割り振った
IDをNode ID項目３０４に、また同一Nodeに存在する端
末数をMax Node項目３０５に格納する。これらの項目３
０１〜３０５から成るレコードは生徒端末１０４が新規
に参加するたびに追加される。なお、Member ID項目３
０２の上位8bitはマルチキャストグループ中のサブグル
ープを表し、上位8bitは生徒端末の識別子が格納され
る。Member ID項目３０２の上位8bitの各bitは１つのサ
ブグループに対応しており、１つのマルチキャストアド
レスに最大８つのサブグループを定義できる。先生端末
１０６におけるユーザ管理テーブル３００が更新された
場合、更新後の内容は全グループのメンバ宛て（生徒端
末）に送信される。

【００１９】図３（ｂ）は、本実施形態でデータの転送
に用いるパケットフォーマットの一例を示す図である。
同報通信時に転送するパケットは、Protocol Header３
１１、Member ID３１２、Transfer Info３１３、Data３
１４から構成される。Protocol Header３１１には、マ
ルチキャストプロトコルのヘッダ(UDPヘッダ)、Member
ID３１２にはパケットを受信すべき端末を識別するため
のMember ID３０２、Transfer Info３１３には高レート
データ転送やデータ転送時の信頼性を向上するための制
御情報、Data３１４には実データが格納される。Transf
er Info３１３は、High Rate Flag３１５、Transfer Ra
te３１６、Total Data３１７、Sequence Number３１８
から構成される。High Rate Flag３１５、は高レートデ
ータ転送開始のフラグ、Transfer Rate３１６は高レー
トデータ転送時のデータ転送レート、Total Data３１７
は高レートデータ転送が終了するまでに転送されるデー
タ量、Sequence Number３１８は転送データの順序情報
が格納される。

【００２０】図４は、同報通信拡張プログラム１３Ａ内
に存在するネットワークインタフェースバッファ１４Ａ
の開放ルーチン２２２の構成を示す図である。同報通信
拡張プログラム１３Ａは、内部にバッファ開放ルーチン
２２２を保持している。バッファ開放ルーチン２２２に
端末ＣＰＵ１３Ｅが割り当てられると、ネットワークイ
ンタフェースバッファ(受信用)１４ＡＲに格納されたデ
ータを参照し、各パケットのMember IDフィールド３１
２（パラメータ）を参照し、自端末のMember ID値とビ
ット積を計算し、“０”以外であった場合はデータを共
有バッファ１３Ｄにコピーする。すなわち、自端末宛の
データであればデータを共有バッファ１３Ｄにコピーす
る。ビット積が“０”の場合はネットワークインタフェ
ースバッファ（受信用）１４ＡＲの領域を開放する。図
４の例では、網掛け部分のMember ID＝２のデータのみが
コピーされ、他は廃棄されることを示している。

【００２１】このように、同報通信データの先頭バイト
をデータ受信メンバを示すパラメータとし、データを受
信した生徒端末１０４がパラメータを解析し、当該受信
データを受信バッファに取り込むか、廃棄するかを決定
する仕組みを設けたことにより、前記パラメータに基づ
き、１つのマルチキャストグループを複数のサブグルー
プに分類することが可能になり、グループ数の増加によ
るパケット数の増大を回避し、サブグループの動的な変
更を容易にすることが可能になる。

【００２２】図５（ａ）は、画面共有プログラム１１Ｂ
が表示画面をウインドウ単位に切り分ける場合に、切り
分ける対象となるデスクトップ領域を示した図である。
表示画面を共有する端末上のデスクトップ領域５１１に
は、複数のアイコン５１２、５１３と複数のウインドウ
５１４，５１５が存在している。画面共有プログラム１
１Ｂは、１つ１つのアイコンやウインドウを単位とし
て、オブジェクトを作成する。個々のオブジェクトには
画面表示データや座標データが格納されている。図５
（ｂ）は画面共有プログラム１１Ｂが作成するウインド
ウテーブルの構成を示した図である。ウインドウテーブ
ル５２０には、Window項目５２１、WindowID項目５２
２、x項目５２３、y項目５２４、sx項目５２５、sy項目
５２６、Depth項目５２７、Handle項目５２８を保持す
るようになっている。

【００２３】デスクトップ領域５１１から切り分けられ
たウインドウ(アイコン)名をWindow項目５２１に格納
し、また個々のウインドウオブジェクトを一意に識別す
るための識別子をWindow ID項目５２２に格納し、さら
にウインドウの左上のｘ座標をx項目５２３、ウインド
ウの左上のｙ座標をy項目５２４、ウインドウの右下の
ｘ座標をsx項目５２５、ウインドウの右下のｙ座標をsy
項目５２６、ウインドウが重なりが存在する場合の階層
の深さをDepth項目５２７、各オブジェクトが格納され
ているメモリ領域のハンドルをHandle項目５２８にそれ
ぞれ格納する。画面共有プログラム１１Ｂはウインドウ
作成、ウインドウ削除、ウインドウアクティブ、ウイン
ドウ再描画などのユーザイベントを捕捉しており、イベ
ントが発生するたびにウインドウテーブル５２０の該当
するレコードを更新し、オブジェクトの更新、オブジェ
クト転送を実行する。

【００２４】このように、先生端末１０６の表示画面情
報をウインドウ単位またはアイコン単位で分類し、その
分類結果をオブジェクトに変換し、オブジェクト単位で
生徒端末１０４に送信することにより、先生端末１０６
と生徒端末１０４とで画面情報を共有している時に画面
情報全体を転送する必要がなくなり、変更があったオブ
ジェクトデータだけを転送するだけで画面共有を実現す
ることができる。また、１回の転送データ量を削減する
ことが可能になる。

【００２５】図６は、高レートデータ受信時に同報通信
拡張プログラム１３Ａがコンテキストスイッチを禁止す
る時の仕組を示す図である。同報通信拡張プログラム１
３Ａは、内部にデータ処理ルーチン４０２とバッファコ
ピールーチン４０３を保持している。タスク管理プログ
ラム１３Ｂは、内部にタイマー割込みルーチン４０５を
保持している。同報通信拡張プログラム１３Ａのデータ
処理ルーチン４０２に端末ＣＰＵ１３Ｅが割り当てられ
ると、データ処理ルーチン４０２は共有バッファ(受信
用)１４ＡＲに格納されているデータのTransfer Infoフ
ィールドを参照する。TransferInfoフィールドのHigh R
ate Flag（図３（ｂ）の３１５）が“０”でない場合、
高レートデータ転送の開始を意味するので、タスク管理
プログラム１３Ｂに高レートデータ転送開始を通知す
る。

【００２６】タスク管理プログラム１３Ｂは通知を受信
すると、速やかにバッファコピールーチン４０３にＣＰ
Ｕ割り当てを行い、割込み時間を設定する。割込み時間
はデータ処理ルーチン４０２が指定した時間が予約値よ
りも小さい場合、指定時間を設定するが、データ処理ル
ーチン４０２が指定した時間が予約値よりも大きい場
合、予約値を設定する。この制御により、バッファコピ
ールーチン４０３が長時間にわたって端末ＣＰＵ１３Ｅ
を占有することから回避できる。バッファコピールーチ
ン４０３は端末ＣＰＵ１３Ｅが割り当てられると、割込
みが発生するまでネットワークインタフェースバッファ
（受信用）１４ＡＲの受信データを処理し、共有バッフ
ァ（受信用）１３ＤＲにコピーする。タスク管理プログ
ラム１３Ｂのタイマー割込みルーチン４０５は、割込み
時間に達したならば、バッファコピールーチン４０３に
割込みを行う。

【００２７】このように、先生端末１０６が同報通信デ
ータを送信している間、生徒端末１０４のコンテキスト
スイッチの切り替えを禁止し、生徒端末１０４のＣＰＵ
をネットワークインタフェース中のバッファ領域を開放
する処理に割り当てることにより、ネットワークインタ
フェース中のバッファが溢れてパケットロスが発生する
ことを回避するが可能になる。

【００２８】図７は、高レートデータ送信時に同報通信
拡張プログラム１３Ａの動作の仕組を示す図である。同
報通信拡張プログラム１３Ａは、データ送信ルーチン４
１２を保持している。同報通信拡張プログラム１３Ａの
データ送信ルーチン４１２に端末ＣＰＵ１３Ｅが割り当
てられると、共有バッファ(送信用)１３ＤＴに格納され
ているデータ量が予約値以上かどうか判断し、予約値よ
りも大きい場合、高レートデータ転送開始パケットを作
成し、ネットワークインタフェースバッファ１４ＡＴに
転送し、このネットワークインタフェースバッファ１４
ＡＴを通じた送信を実行する。以後、データ転送レート
を高レートデータ転送開始パケットで設定した転送間隔
を保持するためのSleep時間を守り、データ転送を持続
する。

【００２９】このように、先生端末は生徒端末１０４、
１０５のプロセッサスケジューリングを制御するため、
生徒端末１０４、１０５へ制御通知パケットを送信する
方法等を利用して生徒端末１０４からの送信データを一
時的に停止し、先生端末１０６から送信されるデータの
転送レートの限界値を一定時間に限り上昇させることに
より、単位時間でのデータ転送量を保証しつつシステム
の効率を向上し、データのコリジョンの発生を抑制する
ことが可能になる。

【００３０】図８（ａ）は、同報通信拡張プログラム１
３Ａが画面共有プログラム１１Ｂにデータ受信通知を実
行するときの動作の仕組を示す図である。画面共有プロ
グラム１１Ｂは、同報通信拡張プログラム１３Ａが保持
するデータ受信通知ルーチン５３１からのデータ受信通
知を待っている。同報通信拡張プログラム１３Ａのデー
タ受信通知ルーチン５３１に端末ＣＰＵ１３Ｅが割り当
てられると、データ受信通知ルーチン５３１は、共有バ
ッファ（受信用）１３ＤＲに格納されているデータの実
データ領域の先頭番地を指すポインタＰのリストを作成
する。画面共有プログラム１１Ｂへのデータ受信通知間
隔は、あらかじめバッファの総データ量dの関数fを定義
しておき、T=f(d)の間隔でデータ受信通知を実行する。
この制御により、共有バッファ１３ＤＲ内のデータが少
ない場合は、長い間隔でデータが処理され、共有バッフ
ァ１３ＤＲ内のデータが多い場合は、短い間隔でデータ
が処理される。

【００３１】したがって、共有バッファ１３ＤＲが溢れ
難くなる。また、端末内のデータ転送レートの動的制御
が可能となり、ネットワークのスループットに依存しな
い伝送品質をアプリケーションに提供することが可能に
なる。

【００３２】図８（ｂ）は、同報通信拡張プログラム１
３Ａが画面共有プログラム１１Ｂからデータ送信通知を
実行するときの動作の仕組を示す図である。画面共有プ
ログラム１１Ｂは、同報通信拡張プログラム１３Ａが保
持するデータ送信通知ルーチン５３２に送信データを与
えるために、共有バッファ(送信用)１３ＤＴ内に領域を
確保し、データを格納する。画面共有プログラム１１Ｂ
は格納したデータのポインタＰを同報通信拡張プログラ
ム１３Ａのデータ送信通知ルーチン５３２に通知する。
データ送信通知ルーチン５３２は与えられたポインタＰ
を利用して送信対象のデータにアクセスし、そのデータ
を転送する単位に分割して、それぞれのブロックの先頭
番地を示すポインタリストを作成する。

【００３３】図９（ａ）は、同報通信拡張プログラム１
３Ａが作成するパケット優先度テーブル６００の構成を
示す図である。パケット優先度テーブル６００は、Sequ
enceNumber項目６０１、Packet Priority項目６０２を
保持するようになっている。データを送信する端末(主
に、先生端末)は、共有バッファ１３Ｄ中のデータに一
意なSequence Numberを割り当て、転送するパケットを
区別できる手段を提供する。Packet Priority６０２
は、本実施形態では３段階のプライオリティを設定し、
パケットを受信した端末のパケットの扱い方を規定して
いる。

【００３４】Packet Priority＝１の場合、全ての端末
はデータを受信できなかった場合、再送要求などによっ
てデータを必ず取得しなければならない。また、受信デ
ータをキャッシュバッファ１３Ｃに保持しなければなら
ない。これに相当するのは、共有する画面データが大き
く変動した場合などが考えられる。Packet Priority＝
２の場合、同一ノードの１台の端末だけが受信データを
キャッシュ保存する。データの受信に失敗した端末はノ
ード内にある他の端末のキャッシュバッファ１３Ｃから
データを取得できればよい。Packet Priority＝３の場
合、データの受信に失敗した場合、データの再送要求を
実行しなくてもよい。また、受信データをキャッシュし
なくてもよい。これに相当するのは、共有する画面デー
タがほとんど変動していない場合など、データを廃棄し
ても表示には影響が少ない場合が考えられる。

【００３５】図９（ｂ）はパケット優先度テーブル６０
０を利用して、受信データをキャッシュ保存する様子を
示す図である。ノード６１１には端末（１１）１０４
Ａ、端末（１２）１０４Ｂ、端末（１３）１０４Ｃが存
在している。端末（１１）１０４Ａにはキャッシュバッ
ファ１３Ｃ１、端末（１２）１０４Ｂにはキャッシュバ
ッファ１３Ｃ２、端末（１３）１０４Ｃにはキャッシュ
バッファ１３Ｃ３がある。図示の例では、Sequence Num
ber n、Packet Priority iのパケットP_i(n)を５回送信
した場合にキャッシュバッファ１３Ｃ１〜１３Ｃ３に格
納されるデータを表している。図ではパケットP₁(1)は
全ての端末にキャッシュ保存されているが、P₂(2)、P
₂(3)、P₂(4)は各端末に分散されており、P₃(5)はどの端
末にもキャッシュされていない。Packet Priority＝２
のパケットを端末ごとに振り分ける処理として本実施形
態では、同報通信拡張プログラム１３Ａ内でMod([Seque
nce Number]/[Max Node]) ＝ Node IDの端末がデータを
キャッシュ保存するというアルゴリズムを採用してい
る。

【００３６】このように、同報通信データの他にパケッ
トの優先度テーブルを送信し、受信側において受信した
優先度テーブルに基づき動的にサービス品質を変更する
ことにより、同一ノード中に存在する各端末が異なる優
先度テーブルを受信することで、同一ノード中の端末で
はキャッシュされるデータが端末ごとに異なることにな
り、キャッシュ使用メモリ領域が削減されるとともに、
あるパケットの再送を受付ける端末がノード内に１台だ
けであり、ノード内の他の端末はパケット再送受付てい
る端末からパケットを取得すればよく、データ再送要求
によるトラフィックの増加を防ぐことができる。

【００３７】図１０(a)は同報通信時のＡＣＫ(応答確
認)を各端末が送信するときの様子を示す図である。図
示の例では、同報通信するデータを送信するノードとし
てノード１(７０１)、同報通信するデータの受信に成功
したノードとしてノード２(７０２)、ノード３(７０
３)、ノード５(７０５)、同報通信するデータの受信に
失敗したノードとしてノード４(７０４)、ノード６(７
０６)の構成を仮定している。図中の（１）はＴＴＬ＝
２でＡＣＫを同報通信で転送することを示し、（２）は
ノード４から見てホップ数１のノードがデータを受信し
たことを隣接ノードに同報通信で転送することを示し、
（３）はホップ数２を指定してデータ再送要求を出す
（ノード２が再送要求に応答する）ことを示している。

【００３８】ノード1から送出するACKパケットはＴＴＬ
＝２である。つまり、ACKパケットは２つのノード中を
送信できるが、３つ目のノードに転送されることはな
く、ルータ等で自動的に廃棄される。つまり、ＡＣＫが
２つのノードをまたいで転送されることはない。ノード
４（７０４）ではデータの受信に失敗しているが、ノー
ド２（７０２）からＡＣＫを受信しているので、ノード
６（７０６）にはノード２（７０２）に受信データの再
送要求を出せばデータが得られることを通知する。通知
を受信したノード６（７０６）は、ノード２（７０２）
にデータの再送要求を送信すればよく、データを送信し
たノード１（７０１）からデータを取得する必要がなく
なる。また、ACKをグループ全体に送信する方法と比べ
トラフィック量も削減できる。

【００３９】図１０（ｂ）は同報通信拡張プログラム１
３Ａが作成する受信データテーブルを示す図である。受
信データテーブル７００は、Sequence Number項目７１
１、Hop項目７１２を保持するようになっている。デー
タを区別するためのSequence Numberとデータをキャッ
シュ保存しているノードとの距離を表すHopがある。デ
ータを受信した端末で、そのデータをキャッシュ保存す
る端末は隣接ノードにＡＣＫを送信する。ＡＣＫを受信
した隣接ノードの端末は、受信データテーブル７００の
該当するレコードのHop７１２を“1”に設定する。ま
た、自端末がデータを受信できた場合、該当するレコー
ドのHopを“０”に設定する。受信データをキャッシュ
しているノードまでの距離の通知を受信した場合、Hop
７１２に距離値を設定する(但し、変更するHop値が既に
格納されているHop値より大きい場合、変更は実行しな
い)。

【００４０】このような制御により、Hop項目７１２に
はデータ再送要求を送信すべき最も近いノードの距離が
格納されるので、データ受信タイムアウトでデータ再送
要求を出さなければならない場合も、効率的にデータを
取得することができる。また、レコードを更新した場合
だけ、近隣ノードに距離の通知を実行することで、無駄
なトラフィックを回避できる。また、データを送信する
先生端末が遠隔地にある場合のＡＣＫ（確認応答）やデ
ータの再送要求を送信時に、端末は遠隔地にある先生端
末にパケットを送信するのではなく、最も近いノードに
ある端末にＡＣＫやデータ再送要求を送信するようなＴ
ＴＬ値を設定することで、ネットワークの冗長なトラフ
ィックを削減するとともに、データを受信することがで
きた端末が代理でデータ再送要求に対してデータを再送
することが可能となり、このようなデータを再送するこ
とができる近隣ノード端末を効率的に発見することがで
きる。

【００４１】図１１(a)は、生徒端末１０４、１０５が
新規にグループに参加した場合の先生端末１０６上で稼
動するユーザ管理プログラム１１Ａの処理を示すフロー
チャートである。生徒端末１０４、１０５は起動時にユ
ーザ管理プログラム１１Ａが実行されマルチキャストグ
ループに参加する処理を実行する(ステップ１１０１)。
グループに参加後、Hello Packetをマルチキャストグル
ープに送信する(ステップ１１０２)。先生端末１０６上
で稼動するユーザ管理プログラム１１Ａは、生徒端末１
０４からのHello Packetを受信すると、生徒端末１０
４、１０５に一意なMember IDを割り当て、図３のユー
ザ管理テーブル２００に新規メンバの情報を追加する
(ステップ１１０３)。先生端末１０６上ではユーザ管理
テーブル２００が更新されたのを契機に、先生端末１０
６上のユーザ管理プログラム１１Ａがマルチキャストグ
ループに対して、ユーザ管理テーブル２００の情報を転
送する(ステップ１１０４)。以降、ステップ１１０１か
ら繰り返す。

【００４２】図１１（ｂ）は生徒端末１０４が新規にグ
ループに参加した場合の生徒端末１０４上で稼動するユ
ーザ管理プログラム１１Ａの処理を示すフローチャート
である。生徒端末１０４上で稼動するユーザ管理プログ
ラム１１Ａは、先生端末１０６からユーザ管理テーブル
２００の情報が受信されるのを待ち(ステップ１１１
１)、先生端末１０６からグループに転送されたユーザ
管理テーブル２００の情報を受信する(ステップ１１１
２)。ユーザ管理プログラム１１Ａは、受信したユーザ
管理テーブル情報からMember項目３０１が自分の端末と
同一であるレコードを検索し、そのMember ID項目３０
２の値を検索する(ステップ１１１３)。そして、検索し
たMember ID項目３０２の値を、自端末を一意に表すID
値として、同報通信拡張プログラム１３Ａに通知する
(ステップ１１１４)。以降、ステップ１１１１から繰り
返す。

【００４３】図１２（ａ）は画面共有プログラム１１Ｂ
が同報通信拡張プログラム１３Ａからデータを受信した
ことを通知されるときの処理を示すフローチャートであ
る。画面共有プログラム１１Ｂは、同報通信拡張プログ
ラム１３Ａからデータ受信通知を待ち(ステップ１２０
１)、データ受信通知を受信する(ステップ１２０２)
と、通知として受け取ったデータのポインタを利用し
て、共有画面の描画処理(スクリーンバッファにデータ
をコピーして再描画処理)を実行する(ステップ１２０
３)。データを利用し終えた後で、共有バッファ１３Ｄ
中のポインタで示される領域を開放する(ステップ１２
０４)。以降、ステップ１２０１から繰り返す。

【００４４】図１２（ｂ）は画面共有プログラム１１Ｂ
がスクリーン上のアクティブなウインドウを利用してウ
インドウオブジェクトを更新するときの処理を示すフロ
ーチャートである。画面共有プログラム１１Ｂは、オペ
レーティングシステムからアクティブなウインドウのハ
ンドル（識別子）を取得する(ステップ１２１１)と、そ
のウインドウハンドルを利用してウインドウオブジェク
トが内部に保持するイメージデータを切り出す(ステッ
プ１２１２)。そして、アクティブウインドウの座標、
デスクトップ上での階層を検出し、図５のウインドウテ
ーブル５２０の該当する項目を更新する(ステップ１２
１３)。その後、所定時間Sleepによって処理を停止し
(ステップ１２１４)、ステップ１２１１から繰り返す。

【００４５】図１３(ａ)は画面共有プログラム１１Ｂが
デスクトップ領域５１１から新規ウインドウに対するオ
ブジェクトを作成したり、削除されたウインドウに対す
るオブジェクトを削除し、ウインドウテーブル５２０を
更新するときの処理を示すフローチャートである。画面
共有プログラム１１Ｂはユーザイベントを捕捉しており
(ステップ１３２１)、捕捉したイベントの中にウインド
ウ作成イベントやウインドウ削除イベントを発見した場
合(ステップ１３２２)、オペレーティングシステムが保
持しているウインドウリストとウインドウテーブル５２
０が同一かどうか調べ(ステップ１３２３)、同一の場
合、ステップ１３２１から繰り返す。しかし、同一でな
い場合、どのウインドウが追加されたのか削除されたか
をオペレーティングシステムのウインドウリストとウイ
ンドウテーブル５２０との比較から検出し(ステップ１
３２４)、ウインドウが追加された場合、その追加ウイ
ンドウから座標やイメージデータを切り出し、オブジェ
クトを作成の後、ウインドウテーブル５２０に新規レコ
ードを追加する(ステップ１３２５)。ウインドウが削除
された場合、該当するオブジェクトを削除し、ウインド
ウテーブル５２０から該当するレコードを削除する（ス
テップ１３２６）。以降、ステップ１３２１から繰り返
す。

【００４６】図１３(ｂ)は画面共有プログラム１１Ｂが
表示画面のデータをグループ内の他の端末と共有するた
めに同報通信拡張プログラム１３Ａにデータを受け渡す
場合の処理を示すフローチャートである。画面共有プロ
グラム１１Ｂは共有バッファ１３Ｄ中に領域を確保し
(ステップ１３３１)、確保した共有バッファ１３Ｄの領
域に共有画面データ(オブジェクト、ウインドウテーブ
ル)を格納する(ステップ１３３２)。そして、格納デー
タの先頭ポインタを同報通信拡張プログラム１３Ａに通
知し(ステップ１３３３)、所定時間Sleepによって処理
を停止し(ステップ１３３４)、以降ステップ１３３１か
ら繰り返す。

【００４７】図１４（ａ）は同報通信拡張プログラム１
３Ａがユーザ管理プログラム１１Ａから自端末に割り当
てられた一意なMember IDを通知されたときの処理を示
すフローチャートである。同報通信拡張プログラム１３
Ａはユーザ管理プログラム１１ＡからMember IDの通知
を待ち(ステップ１４０１)、Member IDの通知を受信す
る(ステップ１４０２)と、内部にMember IDを格納して
保持する(ステップ１４０３)。以降、ステップ１４０１
から繰り返す。

【００４８】図１４（ｂ）は同報通信拡張プログラム１
３Ａ内のデータ処理ルーチン（図６の４０２）が高レー
トデータ転送開始を検出するときの処理を示すフローチ
ャートである。同報通信拡張プログラム１３Ａのデータ
処理ルーチン４０２は、端末ＣＰＵが割り当てられるの
を待ち(ステップ１４０１)、端末ＣＰＵが割り当てられ
る(ステップ１４０２)と、共有バッファ１３Ｄの受信バ
ッファ１３ＤＲ中に未処理データがあるかどうか調べる
(ステップ１４１３)。バッファ中に未処理データがない
場合はステップ１４０１から繰り返す。バッファ中に未
処理データがある場合、バッファ中の未処理データの先
頭を調べ、Transfer Info項目のHigh Rate Flagの値を
取得する(ステップ1014)。High Rate Flag の値が
“０”かどうかを調べ(ステップ１４１５)、“０”の場
合、高レートデータ転送が開始されていることを示して
いるで、タスク管理プログラム１３Ｂに、バッファコピ
ールーチン（図６の４０３）に端末ＣＰＵ１３Ｅを割り
当て、指定時間割込み禁止するように要求する(ステッ
プ１４１６)。ステップ１４１６まで進んだならば、以
降、ステップ１４１１から繰り返す。ステップ１４１５
で、High Rate Flagが“０”でなかった場合、１つのデ
ータの処理が終了したので、ステップ１４１３から繰り
返す。

【００４９】図１５は、同報通信拡張プログラム１３Ａ
のバッファコピールーチン４０３（図６）がデータ受信
のＡＣＫ(応答確認)を送信する場合の処理を示すフロー
チャートである。同報通信拡張プログラム１３Ａのバッ
ファコピールーチン４０３は、端末ＣＰＵ１３Ｅが割り
当てられるのを待ち(ステップ１５２１)、端末ＣＰＵ１
３Ｅを割り当てられる(ステップ１５２２)と、ネットワ
ークインタフェースバッファ１４Ａ内の受信データを共
有バッファ１３Ｄにコピーし(ステップ１５２３)、受信
応答確認を近隣ノードにだけ転送するため、TTL＝２で
ＡＣＫを送信する(ステップ１５２４)。以降、ステップ
１５２１から繰り返す。

【００５０】図１６は、同報通信拡張プログラム１３Ａ
のデータ送信ルーチン４１２（図７）が高レートデータ
転送するのか一般的な転送レートでデータ転送するか判
断するときの処理を示すフローチャートである。同報通
信拡張プログラム１３Ａのデータ送信ルーチン４１２
は、端末ＣＰＵ１３Ｅが割り当てられるのを待ち(ステ
ップ１６３１)、端末ＣＰＵ１３Ｅが割り当てられる(ス
テップ１６３２)と、共有バッファ１３Ｄの送信バッフ
ァ１３ＤＴ中に未処理データがあるかどうか調べる(ス
テップ１６３３)。送信バッファ１３ＤＴ中に未処理デ
ータがない場合はステップ１６３１から繰り返す。しか
し、送信バッファ１３ＤＴ中に未処理データがある場合
は、この送信バッファ１３ＤＴ中の未処理データの総バ
イト数があらかじめ決めてある値を超えているかどうか
調べる(ステップ１６３４)。送信バッファ１３ＤＴ中の
データの総バイト数が一定値以上でない場合、未処理デ
ータをネットワークインタフェースバッファ１４Ａにコ
ピーし、そのデータを転送する(ステップ１６３５)。こ
の後、一般データ転送レートとして、あらかじめ決めら
れている転送レートを保証するためのSleepを実施し(ス
テップ１６３６)、ステップ１６３３から繰り返す。ス
テップ１６３４において送信バッファ１３ＤＴ中の未処
理データの総バイト数が一定値以上の場合、高レートデ
ータ転送開始通知パケットを作成し、グループに送信す
る(ステップ１６３７)。この後、引き続き未処理データ
を、総バイト数が一定値を超えなくなるまで、対象とな
るデータを高レートで、連続して、ネットワークインタ
フェースバッファ１４Ａにコピーする(ステップ１６３
８)。以降、ステップ１６３１から繰り返す。

【００５１】図１７は、同報通信拡張プログラム１３Ａ
のデータ受信通知ルーチン５３１（図８）が、画面共有
プログラム１１Ｂにデータの受信を通知するときの処理
を示すフローチャートである。同報通信拡張プログラム
１３Ａのデータ受信通知ルーチン５３１は、端末ＣＰＵ
１３Ｅが割り当てられるのを待ち(ステップ１７４１)、
端末ＣＰＵ１３Ｅが割り当てられる(ステップ１７４２)
と、共有バッファ１３Ｄ中の受信データのTransfer Inf
oを取り除いた実データ領域の先頭番地を示すポインタ
Ｐを各受信データごとに取得し、ポインタリストを作成
する(ステップ１７４３)。次に、受信バッファ中の総バ
イト数(Total)に関連した関数T=f(Total)によってデー
タ受信通知間隔Ｔを動的に決定する(ステップ１７４
４)。次に、ポインタリストに未処理データがあるかど
うか調べ(ステップ１７４５)、未処理データがない場
合、ステップ１７４１から繰り返す。しかし、未処理デ
ータがある場合、画面共有プログラム１１Ｂにデータ受
信通知として、データのポインタＰを転送し(ステップ
１７４６)、画面共有プログラム１１Ｂがデータにアク
セスすることを可能にする。この後、受信通知間隔Ｔ時
間のSleep(ステップ１７４７)の後、ステップ１７４４
から繰り返す。

【００５２】図１８(ａ)は、同報通信拡張プログラム１
３Ａが画面共有プログラム１１Ｂから送信データのポイ
ンタを通知されたときの処理を示すフローチャートであ
る。同報通信拡張プログラム１３Ａは、画面共有プログ
ラム１１Ｂから送信対象データのポインタ受信を待ち
(ステップ１８５１)、送信対象データのポインタＰを受
信する(ステップ１８５２)と、受信したデータのポイン
タＰで示される共有バッファ領域にアクセスし、送信対
象データを送信単位に分割し、個々の送信対象データに
Transfer Infoヘッダを付加する(ステップ１８５３)。
以降、ステップ１８５１から繰り返す。

【００５３】図１８(ｂ)は同報通信拡張プログラム１３
Ａがパケット優先度テーブル６００（図９）の情報を受
信した場合の処理を示すフローチャートである。同報通
信拡張プログラム１３Ａは、パケット優先度テーブル６
００（Packet Priorityテーブル）の受信を待ち(ステッ
プ１８６１)、Packet Priorityテーブル６００の情報を
受信する(ステップ１８６２)と、Packet Priorityテー
ブル６００の検索を開始する。そして、Packet Priorit
yテーブル６００に未処理データがあるかどうか調べ(ス
テップ１８６３)、未処理データがない場合、ステップ
１８６１から繰り返す。しかし、未処理データがある場
合は、Packet Priorityテーブル６００のSequence Numb
er項目６０１の値を調べ、図６で説明した方法などによ
りキャッシュすべきデータかどうか判断する(ステップ
１８６４)。キャッシュすべきデータではない場合、ス
テップ１８６３から繰り返す。キャッシュすべきデータ
の場合、共有バッファ１３Ｄ中の該当するデータをキャ
ッシュバッファ１３Ｃにコピーして(ステップ１８６
５)、ステップ１８６３から繰り返す。

【００５４】図１９は、同報通信拡張プログラム１３Ａ
が隣接ノードから送信される応答確認の処理方法を示し
たフローチャートである。同報通信拡張プログラム１３
Ａは、隣接ノードからの応答確認の受信を待ち(ステッ
プ１９７１)、応答確認を受信する(ステップ１９７２)
と、受信パケットの解析を実行する。最初に受信パケッ
トがＡＣＫかどうか調べ(ステップ１９７３)、受信デー
タテーブル７００（図１０）の該当するレコードのHop
項目７１２の値を近隣ノードと自端末のHop数(Distanc
e)に変更する(ステップ１９７４)。近隣ノードには、変
更したHop項目７１２の値を通知して(ステップ１９７
５)、ステップ１９７１から繰り返す。ステップ１９７
３において、受信パケットがＡＣＫではなく、Hop値の
通知パケットである場合、受信データテーブル７００中
の該当レコードのHop項目７１２の値を比較する。すな
わち、通知を送信した端末と自端末間のHop数と受信し
た値の和を取った値と該当レコード中のHop値の大きさ
を比較し、小さい値を受信データテーブル７００の該当
するレコードのHop値として更新する(ステップ１９７
６)。Hop数が変更された場合に限り、隣接ノードに更新
されたHop値を通知する(ステップ１９７７)。以降、ス
テップ１９７１から繰り返す。

【００５５】図２０(ａ)は、同報通信拡張プログラム１
３Ａがデータの再送要求を送信する場合の処理を示すフ
ローチャートである。同報通信拡張プログラム１３Ａ
は、データ受信タイムアウトしているデータを検出する
(ステップ２００１)と、受信データテーブル７００から
タイムアウトしているデータに該当するレコードを検索
し、Hop項目７１２の値を求める(ステップ２００２)。
そして、求めたHop値をＴＴＬ値に指定してデータの再
送要求をグループに送信する(ステップ２００３)。以
降、ステップ２００１から繰り返す。図２０（ｂ）は、
タスク管理プログラム１３Ｂが高レートデータ転送時の
割込みを制御するときの処理を示すフローチャートであ
る。タスク管理プログラム１３Ｂは、同報通信拡張プロ
グラム１３Ａから指定時間割込み禁止要求を受信する
(ステップ２０１１)と、指定された時間はあらかじめ設
定された値より小さい値かどうかを調べ(ステップ２０
１２)、小さい値の場合、指定された時間割込みなし
で、同報通信拡張プログラム１３Ａのバッファコピール
ーチン４０３（図６）に端末ＣＰＵ１３Ｅを割り当てる
(ステップ２０１３)。以降、ステップ２０１１から繰り
返す。ステップ２０１２で指定時間は上限値より大きい
値の場合、あらかじめ設定されている上限時間だけ割り
込みなしで、同報通信拡張プログラム１３Ａのバッファ
コピールーチン４０３に端末ＣＰＵ１３Ｅを割り当てる
(ステップ２０１４)。以降、ステップ２０１１から繰り
返す。

【００５６】以上のように、本実施形態のシステムにお
いては、 （１）同報通信データの先頭バイトをデータ受信メンバ
を示すパラメータとし、データを受信した生徒端末１０
４、１０５がパラメータを解析し、当該受信データを受
信バッファに取り込むか、廃棄するかを決定する仕組み
を設けたことにより、前記パラメータに基づき、１つの
マルチキャストグループを複数のサブグループに分類す
ることが可能になり、グループ数の増加によるパケット
数の増大を回避し、サブグループの動的な変更を容易に
することが可能になる。 （２）先生端末１０６の表示画面情報をウインドウ単位
またはアイコン単位で分類し、その分類結果をオブジェ
クトに変換し、オブジェクト単位で生徒端末１０４、１
０５に送信することにより、先生端末１０６と生徒端末
１０４、１０５とで画面情報を共有している時に画面情
報全体を転送する必要がなくなり、変更があったオブジ
ェクトデータだけを転送するだけで画面共有を実現する
ことができる。また、１回の転送データ量を削減するこ
とが可能になる。 （３）先生端末１０６が同報通信データを送信している
間、生徒端末１０４、１０５のコンテキストスイッチの
切替を禁止し、生徒端末１０４、１０５のＣＰＵをネッ
トワークインタフェース中のバッファ領域を開放する処
理に割り当てることにより、ネットワークインタフェー
ス中のバッファが溢れてパケットロスが発生することを
回避するが可能になる。 （４）先生端末は生徒端末１０４、１０５のプロセッサ
スケジューリングを制御するため、生徒端末１０４、１
０５へ制御通知パケットを送信する方法等を利用して生
徒端末１０４、１０５のプロセッサスケジューリングを
制御し、生徒端末１０４、１０５からの送信データを一
時的に停止し、先生端末１０６から送信されるデータの
転送レートの限界値を一定時間に限り上昇させることに
より、単位時間でのデータ転送量を保証しつつシステム
の効率を向上し、データのコリジョンの発生を抑制する
ことが可能になる。 （５）ネットワークインタフェースバッファ中の生徒端
末を示すパラメータの領域に直接アクセスし、ネットワ
ークインタフェースバッファ中の同報通信データをカー
ネルバッファにコピーせずに、受信したパケットが必要
なパケットか否かを判断することにより、ネットワーク
インタフェース中のバッファとカーネルバッファ間のバ
ッファコピーのオーバヘッドを回避することができる。 （６）ネットワークインタフェースとアプリケーション
の中間に設けたバッファリング層においてアプリケーシ
ョンデータをバッファリングすることにより、アプリケ
ーションデータをネットワークインタフェースとアプリ
ケーションと共有することで、カーネルバッファからア
プリケーションバッファへのデータコピーのオーバヘッ
ドを回避することができる。 （７）アプリケーションへのデータ受信通知のインター
バルを変更することにより、端末内のデータ転送レート
の動的制御が可能となり、ネットワークのスループット
に依存しない伝送品質をアプリケーションに提供するこ
とができる。 （８）優先度テーブルに基づき動的にサービス品質を変
更することにより、同一ノード中に存在する各端末が異
なる優先度テーブルを受信することで、同一ノード中の
端末ではキャッシュされるデータが端末ごとに異なるこ
とになり、キャッシュ使用メモリ領域が削減されるとと
もに、あるパケットの再送を受付ける端末がノード内に
１台だけであり、ノード内の他の端末はパケット再送を
受付ている端末からパケットを取得すればよく、データ
再送要求によるトラフィックの増加を防ぐことができ
る。 （９）先生端末に対する確認応答または再送要求を自端
末に近いノードの他の生徒端末に送信することにより、
データを送信する先生端末の端末が遠隔地にある場合の
ＡＣＫ（確認応答）やデータの再送要求を送信時に、生
徒端末は遠隔地にある先生端末にパケットを送信するの
ではなく、最も近いノードにある生徒端末にＡＣＫやデ
ータ再送要求を送信するようなＴＴＬ値を設定すること
で、ネットワークの冗長なトラフィックを削減するとと
もに、データを受信することができた生徒端末が代理で
データ再送要求に対してデータを再送することが可能と
なり、このようなデータを再送することができる近隣ノ
ード端末を効率的に発見することができる。 なお、本発明は上記実施形態に限定されるものではな
く、１対多の同報通信を行う各種のシステムに適用する
ことができるものであり、その適用に際しては適用シス
テムに応じて細部を変更して実施することがある。

【００５７】

【発明の効果】以上説明したように、本発明によれば、 （１）コネクション数を増やさずに、グループ内の限定
されたメンバにだけ選択的にデータ転送するなどの柔軟
な同報通信を実現できる。 （２）データ転送レートを向上させた場合に発生するパ
ケットロスの増大を抑制し、同報通信データのスループ
ットを向上させることができる。 （３）データ転送フロー制御を端末内で実行することに
より、リアルタイムアプリケーション実行時の品質の向
上を図り、ネットワークの状態に依存しないシームレス
な描画表示を行うことができる。 （４）同報通信のＴＴＬの設定を動的に変更すること
で、隣接ノードの端末に応答確認を転送する方法を採用
し、ネットワークのトラフィック削減することができる
などの効果がある。

【図面の簡単な説明】

【図１】本発明に係わる教育システム向け同報通信シス
テムのネットワーク構成図である。

【図２】本発明に係わる教育システム向け同報通信シス
テムの端末内アーキテクチャを示す図である。

【図３】本発明に係わる教育システム向け同報通信シス
テムのユーザ管理プログラムが作成するユーザ管理テー
ブルと、パケットフォーマットを示す図である。

【図４】本発明に係わる教育システム向け同報通信シス
テムのネットワークインタフェースバッファの開放ルー
チンを示す図である。

【図５】本発明に係わる教育システム向け同報通信シス
テムのデスクトップ領域およびウインドウテーブルを示
す図である。

【図６】本発明に係わる教育システム向け同報通信シス
テムの高レートデータ転送開始の検出方法を示す図であ
る。

【図７】本発明に係わる教育システム向け同報通信シス
テムのデータ送信方法を示す図である。

【図８】本発明に係わる教育システム向け同報通信シス
テムのアプリケーションへのデータ受信通知方法および
アプリケーションからのデータ受信方法を示す図であ
る。

【図９】本発明に係わる教育システム向け同報通信シス
テムのパケット優先度テーブルおよび受信データキャッ
シュ方法を示す図である。

【図１０】本発明に係わる教育システム向け同報通信シ
ステムの応答確認送信方法および受信データテーブルを
示す図である。

【図１１】本発明に係わる教育システム向け同報通信シ
ステムの生徒端末が新規にグループに参加した場合の先
生端末上で稼動するユーザ管理プログラムの処理および
生徒端末が新規にグループに参加した場合の生徒端末上
で稼動するユーザ管理プログラムの処理を示すフローチ
ャートである。

【図１２】本発明に係わる教育システム向け同報通信シ
ステムの画面共有プログラム１１Ｂが同報通信拡張プロ
グラムからデータを受信したことを通知されるときの処
理画面共有プログラム１１Ｂがウインドウオブジェクト
を更新するときの処理を示すフローチャートである。

【図１３】本発明に係わる教育システム向け同報通信シ
ステムの画面共有プログラム１１Ｂがウインドウテーブ
ルを更新するときの処理および画面共有プログラム１１
Ｂが画面のデータを同報通信拡張プログラムにデータを
受け渡す場合の処理を示すフローチャートである。

【図１４】本発明に係わる教育システム向け同報通信シ
ステムの同報通信拡張プログラム１３Ａが一意なMember
IDを通知されたときの処理および高レートデータ転送
開始を検出するときの処理を示すフローチャートであ
る。

【図１５】本発明に係わる教育システム向け同報通信シ
ステムの同報通信拡張プログラム１３Ａがデータ受信の
応答確認を送信する場合の処理を示すフローチャートで
ある。

【図１６】本発明に係わる教育システム向け同報通信シ
ステムの同報通信拡張プログラム１３Ａがデータ転送レ
ートを決定するときの処理を示すフローチャートであ
る。

【図１７】本発明に係わる教育システム向け同報通信シ
ステムの同報通信拡張プログラム１３Ａが画面共有プロ
グラムにデータの受信を通知するときの処理を示すフロ
ーチャートである。

【図１８】本発明に係わる教育システム向け同報通信シ
ステムの同報通信拡張プログラム１３Ａが画面共有プロ
グラムから送信データのポインタを通知されたときの処
理およびPacket Priorityテーブルを受信した場合の処
理を示すフローチャートである。

【図１９】本発明に係わる教育システム向け同報通信シ
ステムの同報通信拡張プログラム１３Ａが隣接ノードか
ら送信される応答確認の処理方法を示したフローチャー
トである。

【図２０】本発明に係わる教育システム向け同報通信シ
ステムの同報通信拡張プログラム１３Ａがデータの再送
要求を送信する場合の処理およびタスク管理プログラム
が高レートデータ転送時の割込みを制御するときの処理
を示すフローチャートである。

【符号の説明】

１１…端末、１１Ａ…ユーザ管理プログラム、１１Ｂ…
画面共有プログラム、１２…アプリケーションインタフ
ェース、１３…オペレーティングシステムカーネル、１
３Ａ…同報通信拡張プログラム、１３Ｂ…タスク管理プ
ログラム、１３Ｃ…キャッシュバッファ、１３Ｄ…共有
バッファ、１３Ｅ…端末ＣＰＵ、１４…ネットワークイ
ンタフェースカード、１４Ａ…ネットワークインタフェ
ースバッファ、１４Ｂ…ネットワークインタフェースＣ
ＰＵ、１４Ｃ…ネットワークインタフェース、１０１…
ネットワーク、１０２…マルチキャスト対応ルータ
（１）、１０３…マルチキャスト対応ルータ（２）、１
０４…サブネットワーク（１）、１０５…サブネットワ
ーク（２）、１０４Ａ〜１０４Ｃ，１０５Ａ〜１０５Ｃ
…端末（１１）〜端末１ｎ、端末（２１）〜端末（２
ｎ）、２００…ユーザ管理テーブル、５１２，５１３…
アイコン、５１４，５１５…ウインドウ、５２０…ウイ
ンドウテーブル、６００…パケット優先度テーブル、７
００…受信データテーブル。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 藤岡 秀樹 神奈川県横浜市中区尾上町６丁目81番地 日立ソフトウエアエンジニアリング株式会 社内 Ｆターム(参考） 5B069 AA01 AA02 CA13 LA03 LA07 5B089 GA21 GB01 HB18 5K030 GA03 GA04 GA13 HA08 HD03 JT03 KA08 LA02 LA03 LD06 5K034 AA01 AA06 BB07 DD02 EE11 FF01 FF14 GG05 HH01 HH02 HH06 HH11 HH21 MM03 MM08 MM21

Claims (18)

【特許請求の範囲】
1. 【請求項１】 同報通信データを送信する送信側端末
   と、同報通信データを受信する複数の受信側端末とを備
   え、送信画側端末から１ないし複数の受信側端末を指定
   して同報通信データをマルチキャストプロトコルで送信
   する同報通信方法であって、 前記送信側端末から送信する同報通信データの先頭に受
   信側端末を指定するパラメータを付加して送信するステ
   ップと、 それぞれの受信側端末において、送信側端末から受信し
   た同報通信データの先頭に付加されたパラメータを解析
   し、当該同報通信データを受信するか廃棄するかを決定
   するステップとを備えることで、１つの同報通信グルー
   プを複数のサブグループにグループ化することを特徴と
   する同報通信方法。
2. 【請求項２】 前記送信側端末の表示画面情報をウイン
   ドウ単位またはアイコン単位で分類し、その分類結果を
   オブジェクトに変換し、オブジェクト単位で受信側端末
   に送信するステップを備えることを特徴とする請求項１
   に記載の同報通信方法。
3. 【請求項３】 同一のセグメント上に存在している受信
   側端末のプロセッサスケジューリングを制御し、受信側
   端末からの送信データを一時的に停止し、送信側端末か
   ら送信されるデータの転送レートの限界値を一定時間に
   限り上昇させるステップを備えることを特徴とする請求
   項１または２に記載の同報通信方法。
4. 【請求項４】 送信側端末が同報通信データを送信して
   いる間、受信側端末のコンテキストスイッチの切り替え
   を禁止し、受信側端末のＣＰＵをネットワークインタフ
   ェース中のバッファ領域を開放する処理に割り当てるス
   テップを備えることを特徴とする請求項１〜３のいずれ
   か一項に記載の同報通信方法。
5. 【請求項５】 受信側端末においてネットワークインタ
   フェースバッファ中の受信側端末を示すパラメータの領
   域に直接アクセスし、ネットワークインタフェースバッ
   ファ中の同報通信データをカーネルバッファにコピーせ
   ずに、受信したパケットが必要なパケットか否かを判断
   するステップを備えることを特徴とする請求項１〜４の
   いずれか一項に記載の同報通信方法。
6. 【請求項６】 送信側端末及び受信側端末におけるネッ
   トワークインタフェースとアプリケーションの中間に設
   けたバッファリング層においてアプリケーションデータ
   をバッファリングするステップを備えることを特徴とす
   る請求項１〜５のいずれか一項に記載の同報通信方法。
7. 【請求項７】 送信側端末及び受信側端末におけるアプ
   リケーションへのデータ受信通知のインターバルを変更
   するステップを備えることを特徴とする請求項１〜６の
   いずれか一項に記載の同報通信方法。
8. 【請求項８】 送信側端末において同報通信データの他
   にパケットの優先度テーブルを送信するステップと、受
   信側端末において受信した優先度テーブルに基づき動的
   にサービス品質を変更するステップを備えることを特徴
   とする請求項１〜７のいずれか一項に記載の同報通信方
   法。
9. 【請求項９】 送信側端末に対する確認応答または再送
   要求を自受信側端末に近いノードの他の受信側端末に送
   信するステップを備えることを特徴とする請求項１〜８
   のいずれか一項に記載の同報通信方法。
10. 【請求項１０】 同報通信データを送信する送信側端末
    と、同報通信データを受信する複数の受信側端末とを備
    え、送信画側端末から１ないし複数の受信側端末を指定
    して同報通信データをマルチキャストプロトコルで送信
    する同報通信システムであって、 前記送信側端末が、送信する同報通信データの先頭に受
    信側端末を指定するパラメータを付加して送信する手段
    を備え、 それぞれの受信側端末が、送信側端末から受信した同報
    通信データの先頭に付加されたパラメータを解析し、当
    該同報通信データを受信するか廃棄するかを決定する手
    段を備えることを特徴とする同報通信システム。
11. 【請求項１１】 前記送信側端末が、自端末の表示画面
    情報をウインドウ単位またはアイコン単位で分類し、そ
    の分類結果をオブジェクトに変換し、オブジェクト単位
    で受信側端末に送信する手段を備えることを特徴とする
    請求項１０に記載の同報通信システム。
12. 【請求項１２】 送信側端末が、同一のセグメント上に
    存在している受信側端末のプロセッサスケジューリング
    を制御し、受信側端末からの送信データを一時的に停止
    し、送信側端末から送信されるデータの転送レートの限
    界値を一定時間に限り上昇させる手段を備えることを特
    徴とする請求項１０または１１に記載の同報通信システ
    ム。
13. 【請求項１３】 受信側端末が、同報通信データを受信
    している間、受信側端末のコンテキストスイッチの切り
    替えを禁止し、受信側端末のＣＰＵをネットワークイン
    タフェース中のバッファ領域を開放する処理に割り当て
    る手段を備えることを特徴とする請求項１０〜１２のい
    ずれか一項に記載の同報通信システム。
14. 【請求項１４】 受信側端末が、ネットワークインタフ
    ェースバッファ中の受信側端末を示すパラメータの領域
    に直接アクセスし、ネットワークインタフェースバッフ
    ァ中の同報通信データをカーネルバッファにコピーせず
    に、受信したパケットが必要なパケットか否かを判断す
    る手段を備えることを特徴とする請求項１０〜１３のい
    ずれか一項に記載の同報通信システム。
15. 【請求項１５】 送信側端末及び受信側端末が、ネット
    ワークインタフェースとアプリケーションの中間に設け
    たバッファリング層においてアプリケーションデータを
    バッファリングする手段を備えることを特徴とする請求
    項１０〜１４のいずれか一項に記載の同報通信システ
    ム。
16. 【請求項１６】 送信側端末及び受信側端末が、アプリ
    ケーションへのデータ受信通知のインターバルを変更す
    る手段を備えることを特徴とする請求項１０〜１５のい
    ずれか一項に記載の同報通信システム。
17. 【請求項１７】 送信側端末が同報通信データの他にパ
    ケットの優先度テーブルを送信する手段を備え、 受信側端末が、受信した優先度テーブルに基づき動的に
    サービス品質を変更する手段を備えることを特徴とする
    請求項１０〜１６のいずれか一項に記載の同報通信シス
    テム。
18. 【請求項１８】 受信側端末が、送信側端末に対する確
    認応答または再送要求を自受信側端末に近いノードの他
    の受信側端末に送信する手段を備えることを特徴とする
    請求項１０〜１７のいずれか一項に記載の同報通信シス
    テム。