平成 12 年度
学士学位論文RMTP による高効率マルチキャスト配信
High Eﬃciency Multicast Adopted RMTP

1010396

篠原 直之

指導教員

清水明宏

2月5日
高知工科大学 情報システム工学科

要 旨

RMTP による高効率マルチキャスト配信篠原直之

小中学校へのパソコン・インターネット接続の普及により，教育コンテンツを利用した授業が取り入れられるようになった．しかし，活発なネットワークの使用により，ネットワー
ク帯域の不足が生じコンテンツ受信の不具合が起こるようになった．この問題に対処するプ
ロトコルとして RMTP があげられる．
本検討では，高知県学校インターネットプロジェクトを実証フィールドとして，高信頼性と高速性・配信コストにおいて優れているとされる RMTP を用いたデータ配信により，より良い教育コンテンツ閲覧のためのネットワーク環境の確立をめざした．RMTP について
評価・検討した結果，実証フィールドで信頼性のある有効なプロトコルであると分かった．
しかし，検討要素の不足やクライアント環境のばらつきにより，他の学校グループとのグループでも適用できるかどうかという問題点がある．
今後の課題として，今回検討できなかったパラメータの値での検討や他のパラメータでの検討が課題である．

キーワード

RMTP，マルチキャスト，学校インターネット–i–Abstract
High Eﬃciency Multicast Adopted RMTP
Shinohara

NaoyukiIt came to be adopted due to the diﬀusion of the personal computer ・ Internet
connection to the small junior high school.But, the deﬁciency of the network obi stage
arose, and came to happen by the use of the active network. RMTP is given to it asProtocol to cope with this problem.
this thesis aimed at the establishment of the network environment for the better
education contents perusal. It was found out that it was eﬀective protocol in the actual
proof ﬁeld reliability as a result of examining evaluation about RMTP.But, there is aproblem of whether even a group with the school group can apply it due to the dispersionof the deﬁciency of the examination element and the client environment.
An examination by the value of the parameter which couldn’t be examined this timeand an examination in other parameters are subjects as a future subject.

key words

RMTP，Multicast，school internet– ii –

目次
第1章

はじめに

1

第2章

キーワード

3

第3章

研究内容

5

第4章

研究目的

6

第5章

その他の技術背景

7

第6章

RMTP のデータ送信の仕組み

8

第7章

実験方法

10

第8章

結果

11

第9章

まとめ

16

第 10 章 今後の課題

17

謝辞

18

参考文献

19

付録 A

20

サンプルログデータ– iii –

図目次
2.1

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

6.1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

8.1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

8.2

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

8.3

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

8.4

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

8.5

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

8.6

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15– iv –

第1章

はじめに小中学校へのパソコンの普及，インターネット接続の普及により，教育コンテンツの利用が盛んになっている．これにより，学校間でのコンテンツの共有や利用に際しての，効率の良いデータ配信の要求が高まってきている．
平成 11 年度現在，文部科学省（旧文部省）の「学校における情報教育の実態等に関する調査結果」では，公立学校のコンピュータの設置率は全体では 99.3%．小学校では 98.9%．中
学校では 100%だと言う．また，コンピュータを設置する学校における平均設置台数は，全体では 28.4 台．小学校では 15.7 台．中学校では 36.8 台である．そのうち，インターネッ
トに接続している学校は，全体では 57.4 ％．小学校では 48.7%．中学校では 67.8%である．
「IT 国家戦略」の「人材育成の強化」の中で，特に重要なものとして＜小中学校にインター
ネット接続環境を整備＞という項目があげている．また，＜各学校のインターネット接続率
ではなく，教室毎の接続率，児童・生徒のインターネット利用率を問うべき＞とあるように，今後，益々の学校におけるインターネット環境の向上が見込まれている．
このような小中学校におけるインターネット接続環境は，他校生徒との交流や遠隔授業，
情報リテラシに使用されており，多くの学校がホームページを開設している．これにより，リテラシ授業のみならず通常の授業ででも，教育コンテンツを利用する動きが増えてきている．しかし，授業で提示されたコンテンツを各端末より一度に児童・生徒が閲覧しようとする場合，受信までに時間がかかる，うまくコンテンツの受信が出来ないという問題が起こっている．
この問題に対処するプロトコルとして，RMTP(Reliable Multicast Transport Protocol)が上げられる．

–1–

RMTP は高信頼情報分配プロトコルと訳される．RMTP は日本アイ・ビー・エム株式会社東京基礎研究所と日本電信電話株式会社 (NTT) 情報通信研究所との共同研究プロジェク
トで開発されたプロトコルである．このプロトコルは電子新聞・営業情報などのマルチメ
ディア情報を，同時に多数のユーザに効率よく配布するための技術である．
本研究では，実証フィールドである高知県学校インターネットプロジェクトで導入されている RMTP の有効性の検討を行う．

–2–

第2章

キーワード
• マルチキャスト
若しくは IP マルチキャスト．パケット通信技術の 1 つ．単一のパケットで，複数のノードに対して同一データを送信する通信方法をマルチキャストと呼ぶ．

図 2.1• RMTP
RMTP(Reliable Multicast Transport Protocol:高信頼マルチキャスト通信プロトコル) は，IP マルチキャスト機能をその送信システムとして用いる．RMTP は IP マル
チキャスト上に– 再送に基づいたデータ配信の信頼性–3–

– フロー制御方式に基づいたセッション管理– データ送信成功の際のサーバの配信確認機能という信頼性機能を有する．IP マルチキャストの上の RMTP は主要なプラットホー
ムの UDP(User Datagram Protocol) ソケットインタフェースを使って実行される．

–4–

第3章

研究内容
当研究では高知県学校インターネットプロジェクトを実証フィールドとして，高信頼性と高速性・配信コストにおいて優れているとされる RMTP を用いたデータ配信により，より良い教育コンテンツ閲覧のためのネットワーク環境の確立をめざす．

–5–

第4章

研究目的
実証実験により，実証フィールドにおける RMTP の有効性を示す．また，RMTP の特徴である高信頼性と高速性・配信コストの評価・検討を行い，実証フィールドでの最適なパラメータ値の調査を行う．

–6–

第5章

その他の技術背景• UDP
TCP/IP プロトコルにおける, トランスポート層のプロトコル. 2 つのノード上のプロセス間で, ベストエフォート型のデータグラム指向の通信を行なう.

• データグラム指向
データを送受信する場合，送信データに対していちいち受信確認を行なわない通信方
法．確認処理を省いた分，プロトコル処理にかかる負荷は小さいが，確実に届いたかど
うかが分からないという欠点がある．

• ベストエフォート型
ネットワークにおいて，あるサービスのタイプが保証されない通信形態のこと．ネット
ワーク網全体としては最善を尽くすように努力するが，エンド・ツゥ・エンドで見ると，サービスの保証がなく，最悪の場合はまったくサービスが受けられないこともある．

• スループット
コンピュータが処理を行なう速度．ハードウェアデバイス，CPU，バス，メモリ，デバイスドライバ，OS，アプリケーションなど，コンピュータシステムで関連し合うすべての要素を通して，最終的に処理がどれほどの速度で行なわれるかを指す．
「throughput」
は「一定時間に処理される仕事量」という意味．

–7–

第6章

RMTP のデータ送信の仕組み
主にデータ送信は 3 つのステップに分けられる．

1. コネクション確立
2. データ送信→確認応答 or 再送要求
3. コネクション開放
まず，サーバは＜コネクション確立＞をクライアントに送信する．これに対してクライアン
トは＜コネクションの確立応答＞を返す．次に，サーバは＜データ送信＞を開始し，クライ
アント側は正確に受信できた場合は＜確認応答＞を，できなかった場合は＜再送要求＞を返す．要求のファイルがすべて送信されるまで，＜データ配信＞からやり直す．全て終わると最後にサーバから＜コネクション開放＞が出され，クライアントが＜コネクション開放応答＞を返す．
これにより，実際の通信部分は UDP ベースでありながら，データ送信時の信頼性を高めようという技術である．

–8–

図 6.1

–9–

第7章

実験方法
• 実証フィールド
高知県学校インターネットプロジェクトに設置されている，RMTP をつかったネッ
トワークであるメガキャストを使用．サーバは高知 CATV（ケーブルテレビ）．配信
チェック用の管理サーバ，NOC 管理用の AO サーバ，実際の配信を行う配信サーバの3 台の構成．クライアントは小学校に各 15 台，性能の異なる２機種を配置．中学校に各 41 台，単一機種を配置. 学内 LAN には 10Base-T を使用．主回線はサーバ-クライ
アント間で上り 1.5Mbps，下り 10Mbps となっている．

• 検討内容1. スループットの調査
2. 高信頼性の検討
実証フィールドにおいて，配信に関するパラメータ値を変化させることでスルー
プットの調査を行う．今回は，ファイルサイズ，送信レート，クライアント数の変化が与える影響を調べる．

– 10 –

第8章

結果
実験結果のログのサンプルを付録に示す．

RMTP は，ファイルの送信の際にパケットをある程度の大きさのブロックに分割して送信するとこになっている．一定のサイズ以下の場合には，そのままそれを１ブロックとして扱い配信する．本検討ではブロックサイズを 10MB とした．また，クライアント数には小学校１校分・１５台を基準として実験を行う．
まず，１ブロック（10MB) のファイルを１５台のクライアント送る場合の送信レートの変化を表にした．

図 8.1– 11 –

図 7.1 で示すように，100K バイト/ｓまでは送信レートの上がりに比例して，配信時間が短縮している．しかし，200K バイト/ｓでは逆に 50K/ｓの時よりも時間が掛かっている．
理論値としては，１ M バイト＝ 1024K バイトとして計算すると，25・50・100（K バイト/ｓ）では，それぞれ 409.6・204.8・102.4（秒）となるのだが，微妙に上回っているのは，コ
ネクション確立と開放にかかっている時間である．それぞれ，コネクションの確立と開放にかかる時間を下に示す．

図 8.2

次に，図 7.1 の結果を受けて，送信レート 100K バイト/ｓ，クライアント 15 台の時にファイルサイズを変えた場合のスループットを調べて見た．
結果の通り，時間辺りのファイル送信効率は 10MB（＝１ブロック）の時が最も良い．また，図 7.2 でもあったように，5MB の時が最も時間効率が悪く，やはりこれもコネクショ
ン開放に掛かる時間がネックであった．
次に，送信レート 100K バイト/ｓでクライアント数を中学校２校分とクライアント数を増やした．

– 12 –

図 8.3

図 8.4– 13 –

図 7.4 のように，クライアント数が増えると１ブロックのファイルにおける送信ではス
ループットが落ち，それ以下のファイルサイズではスループットが上がるという結果が得られた．
クライアント数が変わるときのデータをまとめてみた．

図 8.5

また，さらにクライアント数を増やしてみた．
（中学校４校分の 164 台・転送レート 100K
バイトｓ）1 ブロックを超えるファイル送信も行った．

– 14 –

図 8.6– 15 –

第9章

まとめ
実証フィールドにおいて，転送レートの最適なパラメータ値は 100K バイト/s になった．
これは，実証フィールドである 10Base-T の LAN の転送速度に近く，転送レートは良い結果が出たといえる．ファイルサイズについては，１ブロック中において最も効率の良い速度が検出できるのは１０ MB ＝１ブロックのサイズであることがわかった．これは，ファイルの実転送時間に比べて，コネクション開放に時間がかかるため，全体の割合としてもっとも良い効率となった．クライアント数については，ファイルの送信や結合に時間はかかるが，ファイル数の増加に対するスルートップの低下はみられなかった．

– 16 –

第 10 章

今後の課題
今回検討できなかったパラメータの値による検討や，他のパラメータによる検討が課題である．
今回は，小学校１校あたりのクライアント数と，１ブロックのファイルを基準にデータを取り，検討してきたが，さらに大きなファイルサイズや多数のクライアント台であった場合の影響がどのようなものか検討する余地がある．

RMTP には今回の検討で行ったパラメータ以外にも様々なパラメータの設定が可能である．たとえば，再送要求がされた場合を考えた待機時間であるとか，1 ブロックあたりのファイルサイズの変更が可能である．再送要求については，ネットワークの階層の深さや，物理的な距離によって＜再送要求＞や＜応答確認＞がクライアント毎にタイミングが違い，一回の待機時間でまかないきれていない場合や，逆に待機時間が長すぎるといった問題が考えられる．ブロックあたりのファイルサイズについては，送信するファイルのサイズによって，最適なブロックサイズがあるかもしれない．
また，今回の実験では十分な根拠であるとは言えないが，性能の違う端末が混在した時のパフォーマンスの低下についても検討の余地がある．

– 17 –

謝辞
高知工科大学工学科情報システム工学科 清水明宏教授には，本論文をまとめるにあたり多大なるご指導，ご鞭撻を賜った．ここに謹んで深謝申し上げる．また，清水研究室の各研究員の方々には，本論文を執筆するにあたり，数々のご教授，ご助力を頂きいた．実際の実験を通して，研究室研究員の方々はもとより，ＮＴＴ-ＡＴの島岡秀之，山崎秀夫の両名には，格別のご協力を頂いた．さらに，実験のために，各小中学校の教員の方々，高知ケーブ
ルテレビにおいては，研究上欠かせないご助力を頂いたことを感謝する．

– 18 –

参考文献[1] 荒井美千子，“祝入門ＴＣＰ/ＩＰ”，ソフトバンク，1996．
[2] Thomas A. Maufer 著，楠本博之 訳,“ＩＰマルチキャスト入門”，共立出版，2000．
[3] http://www.trl.ibm.co.jp/projects/rmtp/[4] http://www.kantei.go.jp/jp/it/[5] http://www.mext.go.jp/index.htm– 19 –

付録 A

サンプルログデータ

Wed Dec 27 13:59:38 2000 RMTPD START (RMTP V2, NORMAL MODE, Infocast V2.5.1a)
DELIVERY START
Wed Dec 27 13:59:38 2000 send mode = normal memory mode (0)Wed Dec 27 13:59:38 2000 send_file=/export/home/megacast/temp/1/10M
Wed Dec 27 13:59:38 2000 file name=10M
Wed Dec 27 13:59:38 2000 sendkey=/var/tmp/eaab491h_
Wed Dec 27 13:59:38 2000 send_rate=100
Wed Dec 27 13:59:38 2000 unicast resending=1
Wed Dec 27 13:59:38 2000 scramble=0
Wed Dec 27 13:59:38 2000 auth=0
Wed Dec 27 13:59:38 2000 multicast addr=226.1.1.1
Wed Dec 27 13:59:38 2000 ttl=3
Wed Dec 27 13:59:38 2000 i/f=0.0.0.0
Wed Dec 27 13:59:38 2000 fsize=0
Wed Dec 27 13:59:38 2000 massblk=0
Wed Dec 27 13:59:38 2000 mbsize=0
Wed Dec 27 13:59:38 2000 per_nack=0
Wed Dec 27 13:59:38 2000 per_susp=0
Wed Dec 27 13:59:38 2000 send_irate=100
Wed Dec 27 13:59:38 2000 backoff=100
Wed Dec 27 13:59:38 2000 no_busy=0
Wed Dec 27 13:59:38 2000 no_nack=0
Wed Dec 27 13:59:38 2000 no_poll=0
Wed Dec 27 13:59:38 2000 port=7002
Wed Dec 27 13:59:38 2000 n_conn=1
Wed Dec 27 13:59:38 2000 n_poll=1
Wed Dec 27 13:59:38 2000 n_rack=1
Wed Dec 27 13:59:38 2000 n_rrdy=1
Wed Dec 27 13:59:38 2000 t_cack=100
Wed Dec 27 13:59:38 2000 t_acknack=50
Wed Dec 27 13:59:38 2000 t_rack=50
Wed Dec 27 13:59:38 2000 t_rrdy=50
Wed Dec 27 13:59:38 2000 width=0
Wed Dec 27 13:59:38 2000 mu_sel=0
Wed Dec 27 13:59:38 2000 uc_max=1
Wed Dec 27 13:59:38 2000 any=0
Wed Dec 27 13:59:38 2000 maxlc=5
Wed Dec 27 13:59:38 2000 maxrc=-1
Wed Dec 27 13:59:38 2000 comp=77– 20 –

Wed Dec 27 13:59:38 2000 maxtime=-1
Wed Dec 27 13:59:38 2000 nabort=1
Wed Dec 27 13:59:38 2000 i_abort=100
Wed Dec 27 13:59:38 2000 nrel=1
Wed Dec 27 13:59:38 2000 i_rel=100
Wed Dec 27 13:59:38 2000 nmconn=0
Wed Dec 27 13:59:38 2000 i_mconn=0
Wed Dec 27 13:59:38 2000 SEND START
Wed Dec 27 13:59:38 2000 MULTICAST ADDR 226.1.1.1
Wed Dec 27 13:59:38 2000 file_size = 10240000
Wed Dec 27 13:59:38 2000 blk_no = 10000
Wed Dec 27 13:59:38 2000 mass_blk=0
Wed Dec 27 13:59:38 2000 cli_num = 42
Wed Dec 27 13:59:39 2000 type=512 len=2
Wed Dec 27 13:59:39 2000 type=513 len=6
Wed Dec 27 13:59:39 2000 type=514 len=5
Wed Dec 27 13:59:39 2000 INVALID USER=keraj029 ADDR=10.122.156.179
Wed Dec 27 13:59:39 2000 INVALID USER=keraj030 ADDR=10.122.156.180
Wed Dec 27 13:59:39 2000 INVALID USER=aoyagij021 ADDR=10.122.152.171
Wed Dec 27 13:59:39 2000 INVALID USER=aoyagij032 ADDR=10.122.152.182
Wed Dec 27 13:59:39 2000 INVALID USER=keraj020 ADDR=10.122.156.170
Wed Dec 27 13:59:39 2000 INVALID USER=johokuj016 ADDR=10.122.151.166
Wed Dec 27 13:59:39 2000 INVALID USER=keraj019 ADDR=10.122.156.169
Wed Dec 27 13:59:39 2000 INVALID USER=aoyagij033 ADDR=10.122.152.183
Wed Dec 27 13:59:39 2000 INVALID USER=aoyagij022 ADDR=10.122.152.172
Wed Dec 27 13:59:39 2000 INVALID USER=keraj036 ADDR=10.122.156.186
Wed Dec 27 13:59:39 2000 INVALID USER=keraj017 ADDR=10.122.156.167
Wed Dec 27 13:59:39 2000 INVALID USER=keraj016 ADDR=10.122.156.166
Wed Dec 27 13:59:39 2000 INVALID USER=yokohamaj018 ADDR=10.122.150.168
Wed Dec 27 13:59:39 2000 INVALID USER=yokohamaj041 ADDR=10.122.150.150
Wed Dec 27 13:59:39 2000 INVALID USER=yokohamaj035 ADDR=10.122.150.185
Wed Dec 27 13:59:39 2000 INVALID USER=aoyagij041 ADDR=10.122.152.150
Wed Dec 27 13:59:39 2000 INVALID USER=aoyagij026 ADDR=10.122.152.176
Wed Dec 27 13:59:39 2000 INVALID USER=aoyagij028 ADDR=10.122.152.178
Wed Dec 27 13:59:39 2000 INVALID USER=aoyagij039 ADDR=10.122.152.189
Wed Dec 27 13:59:39 2000 INVALID USER=yokohamaj038 ADDR=10.122.150.188
Wed Dec 27 13:59:39 2000 INVALID USER=yokohamaj019 ADDR=10.122.150.169
Wed Dec 27 13:59:39 2000 INVALID USER=aoyagij029 ADDR=10.122.152.179
Wed Dec 27 13:59:39 2000 INVALID USER=johokuj014 ADDR=10.122.151.164
Wed Dec 27 13:59:39 2000 INVALID USER=keraj038 ADDR=10.122.156.188
Wed Dec 27 13:59:39 2000 INVALID USER=keraj033 ADDR=10.122.156.183
Wed Dec 27 13:59:39 2000 INVALID USER=keraj040 ADDR=10.122.156.190
Wed Dec 27 13:59:39 2000 INVALID USER=yokohamaj022 ADDR=10.122.150.172
Wed Dec 27 13:59:39 2000 INVALID USER=aoyagij031 ADDR=10.122.152.181
Wed Dec 27 13:59:39 2000 INVALID USER=keraj024 ADDR=10.122.156.174
Wed Dec 27 13:59:39 2000 INVALID USER=keraj026 ADDR=10.122.156.176
Wed Dec 27 13:59:39 2000 INVALID USER=yokohamaj033 ADDR=10.122.150.183
Wed Dec 27 13:59:39 2000 INVALID USER=yokohamaj040 ADDR=10.122.150.190
Wed Dec 27 13:59:39 2000 INVALID USER=yokohamaj039 ADDR=10.122.150.189
Wed Dec 27 13:59:39 2000 INVALID USER=keraj018 ADDR=10.122.156.168
Wed Dec 27 13:59:39 2000 INVALID USER=aoyagij015 ADDR=10.122.152.165– 21 –

Wed Dec 27 13:59:39 2000 INVALID USER=aoyagij019 ADDR=10.122.152.169
Wed Dec 27 13:59:39 2000 INVALID USER=yokohamaj017 ADDR=10.122.150.167
Wed Dec 27 13:59:39 2000 INVALID USER=aoyagij017 ADDR=10.122.152.167
Wed Dec 27 13:59:39 2000 INVALID USER=keraj025 ADDR=10.122.156.175
Wed Dec 27 13:59:39 2000 INVALID USER=keraj028 ADDR=10.122.156.178
Wed Dec 27 13:59:39 2000 INVALID USER=keraj041 ADDR=10.122.156.150
Wed Dec 27 13:59:39 2000 INVALID USER=yokohamaj030 ADDR=10.122.150.180
Wed Dec 27 13:59:39 2000 INVALID USER=aoyagij027 ADDR=10.122.152.177
Wed Dec 27 13:59:39 2000 INVALID USER=aoyagij016 ADDR=10.122.152.166
Wed Dec 27 13:59:39 2000 INVALID USER=keraj034 ADDR=10.122.156.184
Wed Dec 27 13:59:39 2000 INVALID USER=yokohamaj015 ADDR=10.122.150.165
Wed Dec 27 13:59:39 2000 INVALID USER=keraj023 ADDR=10.122.156.173
Wed Dec 27 13:59:39 2000 INVALID USER=keraj027 ADDR=10.122.156.177
Wed Dec 27 13:59:39 2000 INVALID USER=yokohamaj026 ADDR=10.122.150.176
Wed Dec 27 13:59:39 2000 INVALID USER=johokuj017 ADDR=10.122.151.167
Wed Dec 27 13:59:39 2000 INVALID USER=aoyagij035 ADDR=10.122.152.185
Wed Dec 27 13:59:39 2000 INVALID USER=aoyagij038 ADDR=10.122.152.188
Wed Dec 27 13:59:39 2000 INVALID USER=aoyagij025 ADDR=10.122.152.175
Wed Dec 27 13:59:39 2000 INVALID USER=aoyagij034 ADDR=10.122.152.184
Wed Dec 27 13:59:39 2000 INVALID USER=keraj031 ADDR=10.122.156.181
Wed Dec 27 13:59:39 2000 INVALID USER=yokohamaj028 ADDR=10.122.150.178
Wed Dec 27 13:59:39 2000 INVALID USER=yokohamaj031 ADDR=10.122.150.181
Wed Dec 27 13:59:39 2000 INVALID USER=aoyagij030 ADDR=10.122.152.180
Wed Dec 27 13:59:39 2000 INVALID USER=aoyagij023 ADDR=10.122.152.173
Wed Dec 27 13:59:39 2000 INVALID USER=aoyagij020 ADDR=10.122.152.170
Wed Dec 27 13:59:39 2000 INVALID USER=keraj039 ADDR=10.122.156.189
Wed Dec 27 13:59:39 2000 INVALID USER=keraj032 ADDR=10.122.156.182
Wed Dec 27 13:59:39 2000 INVALID USER=keraj022 ADDR=10.122.156.172
Wed Dec 27 13:59:39 2000 INVALID USER=aoyagij018 ADDR=10.122.152.168
Wed Dec 27 13:59:39 2000 INVALID USER=aoyagij040 ADDR=10.122.152.190
Wed Dec 27 13:59:39 2000 INVALID USER=aoyagij024 ADDR=10.122.152.174
Wed Dec 27 13:59:39 2000 INVALID USER=keraj015 ADDR=10.122.156.165
Wed Dec 27 13:59:39 2000 INVALID USER=yokohamaj034 ADDR=10.122.150.184
Wed Dec 27 13:59:39 2000 INVALID USER=keraj021 ADDR=10.122.156.171
Wed Dec 27 13:59:39 2000 INVALID USER=yokohamaj029 ADDR=10.122.150.179
Wed Dec 27 13:59:39 2000 INVALID USER=yokohamaj032 ADDR=10.122.150.182
Wed Dec 27 13:59:39 2000 INVALID USER=yokohamaj036 ADDR=10.122.150.186
Wed Dec 27 13:59:39 2000 INVALID USER=keraj037 ADDR=10.122.156.187
Wed Dec 27 13:59:39 2000 INVALID USER=keraj035 ADDR=10.122.156.185
Wed Dec 27 13:59:39 2000 INVALID USER=yokohamaj025 ADDR=10.122.150.175
Wed Dec 27 13:59:39 2000 INVALID USER=aoyagij036 ADDR=10.122.152.186
Wed Dec 27 13:59:39 2000 INVALID USER=aoyagij037 ADDR=10.122.152.187
Wed Dec 27 13:59:39 2000 INVALID USER=yokohamaj016 ADDR=10.122.150.166
Wed Dec 27 13:59:39 2000 INVALID USER=yokohamaj037 ADDR=10.122.150.187
Wed Dec 27 13:59:39 2000 INVALID USER=yokohamaj021 ADDR=10.122.150.171
Wed Dec 27 13:59:39 2000 INVALID USER=yokohamaj020 ADDR=10.122.150.170
Wed Dec 27 13:59:39 2000 INVALID USER=yokohamaj027 ADDR=10.122.150.177
Wed Dec 27 13:59:39 2000 INVALID USER=yokohamaj024 ADDR=10.122.150.174
Wed Dec 27 13:59:39 2000 INVALID USER=yokohamaj023 ADDR=10.122.150.173
Wed Dec 27 13:59:59 2000 time

20.330 sec CONNECTED 38

time 100.120 sec SENDING retry=0– 22 –

time

33.680 sec SENDING retry=1

Wed Dec 27 14:02:20 2000 UNICAST MODE
Wed Dec 27 14:02:20 2000 COMPLETE 77 %DELIVERY END
RESULT START
10.122.152.151

aoyagij001

COMPLETE*

0 1

10.122.152.152

aoyagij002

COMPLETE*

0 1

10.122.152.153

aoyagij003

FAIL

2 2

10.122.152.154

aoyagij004

COMPLETE*

0 1

10.122.152.155

aoyagij005

COMPLETE*

0 1

10.122.152.156

aoyagij006

COMPLETE*

0 1

10.122.152.157

aoyagij007

COMPLETE*

0 1

10.122.152.158

aoyagij008

COMPLETE*

0 1

10.122.152.159

aoyagij009

COMPLETE*

0 1

10.122.152.160

aoyagij010

FAIL

2 2

10.122.152.161

aoyagij011

COMPLETE*

0 1

10.122.152.162

aoyagij012

COMPLETE*

0 1

10.122.152.163

aoyagij013

FAIL

2 2

10.122.152.164

aoyagij014

COMPLETE*

0 1

10.122.156.151

keraj001

COMPLETE*

0 1

10.122.156.152

keraj002

COMPLETE*

0 1

10.122.156.153

keraj003

COMPLETE*

0 1

10.122.156.154

keraj004

COMPLETE*

0 1

10.122.156.155

keraj005

COMPLETE*

0 1

10.122.156.156

keraj006

COMPLETE*

0 1

10.122.156.157

keraj007COMPLETE*

0 1

10.122.156.158

keraj008

COMPLETE*

0 1

10.122.156.159

keraj009

COMPLETE*

0 1

10.122.156.160

keraj010

COMPLETE*

0 1

10.122.156.161

keraj011

COMPLETE*

0 1

10.122.156.162

keraj012

COMPLETE*

0 1

10.122.156.163

keraj013

COMPLETE*

0 1

10.122.156.164

keraj014

COMPLETE*

0 1

10.122.150.151

yokohamaj001

FAIL

3 2

10.122.150.152

yokohamaj002

COMPLETE*

0 1

10.122.150.153

yokohamaj003

COMPLETE*

0 1

10.122.150.154

yokohamaj004

COMPLETE*

0 1

10.122.150.155

yokohamaj005

COMPLETE*

0 1

10.122.150.156

yokohamaj006

COMPLETE*

0 1

10.122.150.157

yokohamaj007

COMPLETE*

0 1

10.122.150.158

yokohamaj008

COMPLETE*

0 1

10.122.150.159

yokohamaj009

COMPLETE*

0 1

10.122.150.160

yokohamaj010

COMPLETE*

0 1

10.122.150.161

yokohamaj011

COMPLETE*

0 1

10.122.150.162

yokohamaj012

COMPLETE*

0 1

10.122.150.163

yokohamaj013

FAIL

2 2

10.122.150.164

yokohamaj014

COMPLETE*

0 1

PacketType

Send

Receive

DT

13363

0

ACK

0

94

NACK

0

117

– 23 –

BUSY

0

RRDY

0

0
0

ABORT

1

0

POLL

4

0

CONN

5

0

CACK

0

122

REL

1

0

RACK

0

0

MOVE

0

0

SUSP

0

0

FREPO

0

0

time 161.930 sec SEND COMPLETE
CPU USER

0.160 sec SYSTEM

0.230 sec

RESULT END
Wed Dec 27 14:02:20 2000 SEND END– 24 –