高信頼同報での再送機構のAck Implosionの再評価

概要

論文の詳細を見る
本稿では, IPマルチキャストを用いた多端末への高信頼バルクデータ同報転送プロトコルRMTPにおける, Ack Implosionの程度とバックオフ時間の見積りを再評価する。高信頼バルク同報は, インターネットにおける電子新聞の配送の他, 非常に多数の端末への業務用情報の配信設定, 非常に多数のWSへのソフトウェアの導入・更新などの応用において, 転送時間の短縮, ネットワーク及び送信サーバーの負荷の軽減の効果が期待できる。そのデータ転送信頼性を確保するためには, データの受信端にて到着を確認し, 不足するものがあれば再送依頼を送信サーバーへ送る手順が必須となる。1対多端末の通信では, 受信端からの返答は端末数が多くなるにつれて量が大きくなり, 送信サーバーに接続されるネットワークや送信サーバー自身の処理プログラムに対して大きな負荷となり, 受信端末数の増加に応じてスケールすることが難しい。この問題に対し, 受信端末をグループ化してその中でお互いに再送する方式など, 分散した再送機構の提案もあるが, 送信サーバーがデータ配送をすべて管理監督することができなくなり, 業務上必須のデータを配布するには適さない。それに対して, RMTPはAck Implosionを軽減する工夫を施すことによって, 実用上役に立つ数千程度の範囲での受信端末数を実現しようとするものである。高信頼同報バルク転送の手順例として, RMTPでの全体の転送手順を図1に示す。コネクション設定フェーズで, 送信サーバーと個々の受信端末の間にコネクションを設定する。これは送信端からマルチキャストを用いてコネクション設定メッセージを送り, 受信端がそれに応答する。この応答はすでにAck Implosionの可能性があるが, Ackパケットが短いため程度は軽い。次にデータ転送フェーズに入り, 送信サーバーはマルチキャストで一連のデータを送信してしまう。この間に起こったパケット損失は受信側に記録され, 送信終了後にNackによる再送要求を送り返す。すべてのデータを受信できた端末はAckを返送する。AckかNackかを必ず返送することにより, 送信端での受信状況の把握が確実なものとなる。このAck/NackはImplosionを起こす可能性がある。すべてのデータを受信できAckを返した端末は, 送信サーバからのコネクション解放メッセージをトリガーにして, 同報サービスから離れる。再送を必要とする受信端末は, 1回目のデータ転送と同様の手順で受信に失敗したデータを受信する。再送もマルチキャストを用い, コネクション解放せずに残っているすべての受信端末に対して(そのデータが必要であるなしにかかわらず)送られる。受信端末は必要なデータを受信し, もしすべてのデータが揃えばコネクション解放へ, まだ不足があれば再送要求のNackを送信サーバーに返し, 更に再送を受ける。この手順を, すべての端末がすべてのデータを受けとるまで, 繰り返す。
一般社団法人情報処理学会の論文
1997-09-24

高信頼同報での再送機構のAck Implosionの再評価

スポンサーリンク

概要

著者

関連論文

スポンサーリンク