FTP ダウンロードの中断

Linux-2.6.18-at9　Debianです。

一度受信を開始してしまったFTP転送を中断、再開はできるのでしょうか？。

状況：
タスク１．ハードウエアへのデータバースト転送（ｉｏｃｔｌによる）　：　約5msec
タスク２．Host　PCへのステータス転送（ＰＣ側がClientのTCP/IP）　：約2msec
タスク３．PCから大量データをファイルの形で受信するタスク（FTP　Client）　：残り

が基本タスクとなるシステムがあります。これがWhile文でLoopしており、約50msecに１回タスク１，２が実行されなければなりません。

FTP　Client機能によるファイル受信は50msecのloop時間よりははるかに長く設定されています。
そこでタスク1の実行を阻害しないことを期待してFTP受信タスクを別スレッドにしました。しかし別スレッドではあっても一度始まってしまったファイル受信は中断はできないらしく明らかにタスク１の実行は影響を受けています。
次に別スレッドではなくこれを別のＰｒｏｃｅｓｓにしました。しかし結果は多少は改善しましたが基本的には同じです。

ファイル受信processの要旨は以下のごとくです：
while(1){
errno = 0;
if(msgrcv(msqid, &message, BUFSIZ, read_type, 0) == -1){
perror("msgrcv failure");
break;
}
if (inhbit){
if (filexchg){
system("msh fileRcv.sh file.1"); // msh : bash機能のshell fileRcv.sh : Shell Script
else
system("msh fileRcv.sh file.2");
}
}
二つのファイルを親processの指令とタイミングで交互にダウンロードします。
ｆｔｐクライアントの起動にはｓｈｅｌｌを使っています。

タスク1の実行サイクルが回ってきたら、親がinhibitを発行、ＦＴＰ受信を中断してもらいたいのですが、bashという別のprocessにコントロールを渡しているのですから、本質的に不可能なことをしているように思います。
仮にFTPのフロー制御ができても再開したときFTP転送の障害が発生する懸念もあります。
親、子間の優先順位をいじることで親のタスクを無条件に優先させる設定ができても親にはIldeループもあり子からみた識別はできません。
タスク1の割り込み化も試みたのですが、実現できませんでした。

何か解決策があればお願いいたします。
TCP/IPにすればパケット単位のフロー制御ができることはわかっているのですが、転送速度が問題になります。

No.1 ベストアンサー 回答者： gamera4500 回答日時： 2011/05/16 12:06

こんにちは

あまり内容が理解できたませんが、解る範囲で書きます。

＞一度受信を開始してしまったFTP転送を中断、再開はできるのでしょうか？。
中断は何かしらの方法で可能でしょうが、FTPでは1個のファイルの再開という
ものはありませんので、１個のファイルは転送しなおしになると思います。


＞TCP/IPにすればパケット単位のフロー制御ができることはわかっているのですが、
転送速度が問題になります。

ここの部分は勘違いです。
FTPもTCP/IP通信です。
プログラム構成は
作った通信プログラムー＞FTP通信－＞TCP/IP通信
となっていますので、FTPを使用しないと考えているならば
作った通信プログラムー＞FTPに相当する作ったプログラム－＞TCP/IP通信
となります。
FTPに相当する作ったプログラムはそう簡単には作れないです。

私からのアドバイス

(1)ファイル転送が５０ｍｓに終わる量であるのか計算する
(2)終わらないのならば５０ｍｓでの制御は元々不可能
(3)終わらないならば転送するファイルの量を減らす
(4)FTPで転送はする
(5)何を作成しているかわかりませんが工業用ロボット
　みたいなものであれば(1)(2)は必須
(6)ファイル転送は、システム的のあればいいだけ
　（時間とはあんまし関係ない）のならば、
　ファイル送信を監視し、終わったならばデータを
　更新する（５０ｍｓの世界から切り離す）

と適当なことを書いてます。それでは

この回答への補足

gamera4500様
Resありがとうございます。

ご指摘のようにファイルを送信時間50msec以下となるサイズに分割し、肝心のタスク1の終了直後にFTP受信を開始するようにやってみました。
しかし思わしい結果はえられませんでした。原因は不明ですがファイルが小さすぎてサーバであるWindows側でのファイルopen／closeのオーバヘッドの効果が働いたせいではないかと推察しています。

FTPもTCP/IPが基礎にあることは知識としては持っています。しかしTCP/IPはパケット単位で受信を停止再開することはできると思います。Windows側のサーバソフトも自作しているからです。クライアント側はタスク1仕掛中は禁止フラグをあげ、サーバ側に伝えます。本来ハンドシェークしてくれているはずのTCP/IPコネクションを別の信号で制御するという変則的な形にはなりますが。
ただ50msに一回5msの間だけ受信を中断するのですから回線にあるバッファ効果で持ちこたえてくれるような期待も若干はあります。

Linux側が必要とするデータ量は50msあたり３２ｂｉｔレジスタ数で2048です。Linux側のパケットの設定は3000弱となっており、レジスタ1個を１０バイトの文字列にしているので２５６×１０つまり256Reg伝送できます。であれば１０パケットが約40msの間に受信できれば基本的には充足します。
Ehternetは１００Baseですが、１パケットの受信時間は１～２ｍｓらしいので十分可能と判断しました。

50msの世界と切り離すため受信タスクの専用スレッド化、あるいは専用プロセス化により『BackGroud化』を試みたのですが、Single　CoreのPowerPC、内部クロック３００MHｚではLinux　OSも工夫の余地がなかったのでしょう。

何かご意見があればお願いいたします。

補足日時：2011/05/16 17:52