Japan QualNet Community Forums Japan QualNet Community Forums
Welcome Guest 
ログイン
ユーザ名:

パスワード:


パスワード紛失

新規登録
検索

高度な検索
メインメニュー
アクセスカウンター
2024/05/18：12/14
2024/05/17：19/24
2024/03/19より398/1408
人気モジュール
No.1： フォーラム 115
No.2： QualNet概要 4
No.3： ニュース 2
日曜日からの合計
人気Browser＆OS
No.1：巡回ロボット90
No.2：Unknown OS1
No.3：Windows NT1
No.1：どっかの巡回ロボット81
No.2：Majestic-12巡回ロボット6
No.3：Google巡回ロボット3
日曜日からの合計
メイン
   Application Layer Protocol Implementation & Model Development
     FTP/GENERICモデルでの受信パケットサイズに差異		投稿するにはまず登録を

スレッド表示 | 新しいものから 前のトピック | 次のトピック | 下へ
投稿者 スレッド
yilab
投稿日時: 2006/8/22 6:54
半人前
登録日: 2005/11/3
居住地:
投稿: 23
FTP/GENERICモデルでの受信パケットサイズに差異
いつもお世話になっております．
現在，QN3.9を用いています．


FTP通信において，ペイロードサイズを1400byteに指定したく思っています．
それには，FTP/GENERICモデルを用いて，default.appに以下のような記述をしました．

引用：
FTP/GENERIC 1 2 0 1400 10 60 PRECEDENCE 0



実行してみたところ，statファイルの統計値からはペイロードサイズが変更されているように思えませんでした．
（1400byteを100個受信しているのに，総受信byteは51200byteになっていました）


意図した動作をしているかデバッグ情報を見てみたところ，

引用：
GENERIC FTP Client: Node 1 sending pkt of size 1400 at 10007965442
GENERIC FTP Client: Node 1 at 10007966442 sent data 1400
GENERIC FTP Server: Node 2 at 10084072297 received data 512


となり，送信はできているものの，受信プロセスにおいて512byteに書き換えられてしまっています．
どのレイヤーで書き換わっているのかまでは調べることができず，送信時間等にどれだけ影響がでているかは不明ですが，どういった取り扱いがなされているのでしょうか？
また，QN3.9.5ではこの点が改善されているのでしょうか？
marimo
投稿日時: 2006/8/22 8:33
常連
登録日: 2005/9/22
居住地:
投稿: 49
Re: FTP/GENERICモデルでの受信パケットサイズに差異
自分もQualNet3.9を使っているのですが、特に問題ないような…
単純にアプリケーションを設定したシナリオを添付しますね。

test.zip

見てみると、1400Bytes x 100個を1.3秒ほどで送受信し終えて、
2,,[2],Application,Gen/FTP Server,Total Bytes Received = 140000
となっています。
ちなみにアプリケーション設定ファイルは

%~ cat test/test.app
FTP/GENERIC 1 2 100 1400 1 25 PRECEDENCE 0

で、送信アイテム数は100個に指定していますが、0にしても同様でした。

＃　512というのは…再現できなかったのでちょっと分かりませんが、
＃　もし可能性としてあり得るとすれば、何か別のパケット受信、もしくは値を見ている、とかでしょうか？

%~ cd $QUALNET_HOME/; grep 512 */*.h
application/olsr-inria.h:#define MAXPACKETSIZE       512 /* max broadcast size */
include/external_socket.h:#define EXTERNAL_DEFAULT_VAR_ARRAY_SIZE 512
include/message.h:// CONSTANT    :: MSG_MAX_HDR_SIZE             :   512
include/message.h:#define MSG_MAX_HDR_SIZE                           512
mac/mac_802_3.h:// CONSTANT    :: MAC802_3_MINIMUM_FRAME_LENGTH_GB_ETHERNET : 512
mac/mac_802_3.h:#define MAC802_3_MINIMUM_FRAME_LENGTH_GB_ETHERNET   512

＃　うぅむ、色々ありますね。。

全然解決方法にはなっていませんが、何かのご参考になれば幸いです。
penguish
投稿日時: 2006/8/22 9:56
常連
登録日: 2005/4/8
居住地:
投稿: 45
Re: FTP/GENERICモデルでの受信パケットサイズに差異
Packet Tracer で確認するのも手かなと思いました。
yilab
投稿日時: 2006/8/24 7:59
半人前
登録日: 2005/11/3
居住地:
投稿: 23
Re: FTP/GENERICモデルでの受信パケットサイズに差異
返信ありがとうございます．


各設定を確かめて，もう一度実行し直してみたところ，
おっしゃるとおり 1400Bytes x 100個＝140000 となりました．

しかし，問題はデバッグ情報で，依然として512byteを受信したことになっています．

引用：
GENERIC FTP Client: Node 1 sending pkt of size 1400 at 10007965442
GENERIC FTP Client: Node 1 at 10007966442 sent data 1400
GENERIC FTP Server: Node 2 at 10084072297 received data 512


これはおそらく，トランスポート層において512byteに分割して送信されているのではないかと思います．
FTPの受信パケット数を数えたところ，TCPの受信パケット数と等しくなりました．
TCPにおいて分割されたデータは，受信時においてトランスポート層が責任を持って
復元すべきと思うのですが，そのままアプリケーション層に転送してしまうようです．．．
（TCPの仕様をよく知らないので，あくまで私の所見ですが…）

私が実現したい機能は，*.statファイルに受信パケット数を出力することなので，
単純に総受信バイト数から逆算するようにして，この問題は一件落着としたいと思います．
お騒がせして申し訳ありませんでした．．．


ちなみにデバッグ情報は，gen_ftp.cppで，

#define DEBUG

を定義して再コンパイルし，実行した際に標準出力に出力される結果を指しています．
penguish
投稿日時: 2006/8/24 16:53
常連
登録日: 2005/4/8
居住地:
投稿: 45
Re: FTP/GENERICモデルでの受信パケットサイズに差異
横からすみません。

引用：

yilabさんは書きました：

これはおそらく，トランスポート層において512byteに分割して送信されているのではないかと思います．
FTPの受信パケット数を数えたところ，TCPの受信パケット数と等しくなりました．


ということは Max Segment size を 512byte にしている？　ということですかね？　変更したらできるのでは？ トレースかけて SYN がどの位のMSSでコネクションを要求しているか見てみるといいと思います。

MSSを大きくしすぎるとIPでフラグメントされてしまうかもしれませんね。却って効率が悪いこともあると思います。

引用：

TCPにおいて分割されたデータは，受信時においてトランスポート層が責任を持って
復元すべきと思うのですが，


IP フラグメントでは　IPが責任を持って復元しますが、TCPは違うと思いますよ。順序どおりに届いて間違いなければ上にあげるだけで、あとはアプリケーションが期待したサイズのデータを受け取ったら、あるいはバッファサイズを満たしたらバッファから取り出すだけだと思います。
yilab
投稿日時: 2006/8/26 18:21
半人前
登録日: 2005/11/3
居住地:
投稿: 23
Re: FTP/GENERICモデルでの受信パケットサイズに差異
ご返信ありがとうございます．

引用：

Max Segment size を 512byte にしている？　ということですかね？　変更したらできるのでは？ トレースかけて SYN がどの位のMSSでコネクションを要求しているか見てみるといいと思います。

MSSを大きくしすぎるとIPでフラグメントされてしまうかもしれませんね。却って効率が悪いこともあると思います。


configファイルを確認したところ，TCP-MSS 512とバッチリ書かれていました．
MSSを変更すると，おっしゃる通り効率が悪くなってしまうことも考えられます．私の研究分野はMAC層なので，トランスポート層には極力変更を加えたくないところですが，評価の際にMSSの変更も考えてみたいと思います．

引用：

IP フラグメントではIPが責任を持って復元しますが、TCPは違うと思いますよ。順序どおりに届いて間違いなければ上にあげるだけで、あとはアプリケーションが期待したサイズのデータを受け取ったら、あるいはバッファサイズを満たしたらバッファから取り出すだけだと思います。


そうだったのですか，簡単な仕組みになっているのですね．勉強になります．
スレッド表示 | 新しいものから 前のトピック | 次のトピック | トップ
Forum Option
Copyright c KOZO KEIKAKU ENGINEERING Inc. All Rights Reserved.
XOOPS Cube PROJECT