高速シリアル通信での大容量のデータ転送について(mscomm)

質問

現在高速シリアル通信のプログラムを作成しています。なかなか検索で
いろいろと探しているのですがデータ容量が増えるとどうしてもサンプル
プログラムで同じ結果になってしまいます。
どういう現象かといいますと10000バイトぐらいのデータを転送するとどう
してもデータ上のかけ落ちが発生します。
ボーレート：38400 or 19200bps
データビット：８Bit　パリティ：なし　ストップビット：１Bit
フロー制御：XonXoffRTSCTSあり　データはバイナリィ転送です。
==>送信側のプログラムでは以下通りです。
　　'バイナリデータファイルを読み込み
For i& = LBound(bytBuf) To UBound(bytBuf)
bytedata(LineCnt) = bytBuf(i&)
If (LineCnt < 255) Then　'255バイトずつ分割して送信
bytedata(LineCnt) = bytBuf(i&)
Else
'タイマー処理（wait制御）
MSComm1.Output = bytedata
LineCnt = 0
bytedata(LineCnt) = bytBuf(i&)
End If
LineCnt = LineCnt + 1
Next i&
'WAIT掛けたり分割してデータを転送したり一括でデータを転送したり
行っています。
==>受信側では以下の通りとなっております。
Select Case MSComm1.CommEvent
　　 Case comEvReceive '受信データの取得
Buffer = MSComm1.Input　'あとはバイトデータを結合させて
　　　　　　　　　　　　　　　　　　　'おります。
データの送信や受信について教えていただきたいのですが特に受信側で
私が思うのでは送信データが早すぎて受信側が追いついていない状態
と思うのですが・・・
なにかいい方法や参考になるホームページ等がありましたら伝授お願いします。

回答No.3

ykkw_2001

再度 ykkw_2001 です。

きょうび、プロトコルを組んでみようかなというお考えに
「これでも、わし、昔は女にモテたんじゃ」と自慢話をするジジィのような心境で、再度お送りします。

結局、ブロック（パケット）サイズの決めかたは、経験です。（＾＾）
「ヲイヲイ、のっけからアんだよ」と思うでしょうが、
影響する因子が多くて、キチッと最適値を出すための苦労より、適当に２～３種類試して、エイッと決めてしまうほうが効率的です。

通信に使用しているものすべての応答・動作速度やバッファ・キャッシュサイズが影響します。
通信頻度、標準的な転送サイズ、伝送線、プロトコル（物理層）、ＣＰＵ＋メモリ＋ＨＤＤ＋ＳＩＯのチップ etc...
しかも、転送サイズ・内容がかわっても、常時最高速度で、最高信頼性を確保するのはとても難しいです。

私がお勧めする実践的な目安は、
ＳＩＯのバッファサイズ（ＵＳＡＲＴ）の１０％以下で、
ただ、デバッグや、ラインモニタの性能を考慮して数百バイトでいいと思います。
＃　それを早く言えよ。

＞データを送信したときに受信側から・・送信データがOKでしたよといった返答
＞が帰ってくるのを待つということですね

そのとーりっ　（アタック25児玉清風）

さらに、高速化のためには、ブロック数通知後、受信側では、データ要求をガンガン出す。
送信側から要求されたブロックをガンガン送る。
という荒技手順もありえます。（全２重で）
＃　割り込み（マルチスレッド）使いますので、ＶＢではムリか・・

＞高速化の手法ってどんな方法なのでしょうか！

　上記以外には、データ圧縮もあります。

たとえば、
＞10000バイトぐらい
を
＞38400 or 19200bps
のシリアルで、メモリ上のデータを転送するなら、１秒位かけて、送受信のＣＰＵで圧縮・伸長してもシリアルを通るサイズがそれ以上に減れば高速化できます。

＃　こんなのを確認しつつ考えるのが、すんごく楽しいわけで・・・・
＃ 状態遷移図やら、マトリクスになると快感アルファ波でまくります。・・・（変？）
＃　最近、プロトコル組んでないので、思い出してムラムラしてきました。・・・（やっぱ変・・態・・）
＃　ファイル転送のフリーウェアでもアップしようかな・・・なんて。

で、思い出しましたが、ベクタあたりにＺモデムとかＸモデムのライブラリ（ＤＬＬ）があれば、
それを使う手もありますね。
＃ 先に言え

お礼

いろいろとご指導ありがとうございます。
>結局、ブロック（パケット）サイズの決めかたは、経験です。（＾＾）
私もWAIT掛けたりサイズを変更したりいろいろと試してみました。
タイミングによってデータの取りこぼしが減ったりいろいと変わり
ましたので・・・いろんなパターンで試しています。

一度プログラムを白紙に戻し、現在チャックサムを加えたパケットデータ
での通信に切り替えて作り変えております。
こういうときは・・・位置から作る方がいいですねぇ～（頭がすっきりして）

>ベクタあたりにＺモデムとかＸモデムのライブラリ（ＤＬＬ）
一度探してみます。

toshi0304でした。

回答No.2

terra5

>フロー制御：XonXoffRTSCTSあり　データはバイナリィ転送です。

確認ですが、フロー制御はハードウェア(RTS/CTS)ありで、
ソフトフロー制御(Xon/Xoff)は使っていないですよね。

同時に使うと言う設定は通常無いと思いますし,
バイナリィではXon/Xoffは使えません。

あと、接続に使っているケーブルの結線は把握していますか。
クロスケーブルでの接続だと物によるとハードフロー制御が利きませんので,
データの取りこぼしがでます。

また、送信,受信に使っているマシンのOSやCPU、メモリ等はどの程度でしょうか。
非力な環境だと処理が間に合わない可能性もありえるかと思います。VBAお使いのようですし。

そういえば、昔はシリアル制御CHIPの問題で、
MS-DOS標準のドライバだと取りこぼして使い物にならないって話があったりしました(^^;

補足

VB側のプログラム側で設定すれば使えると思っていました。
すいません私の勉強不足で（とほほほぉ～）
>あと、接続に使っているケーブルの結線は把握していますか。
>クロスケーブルでの接続だと物によるとハードフロー制御が利きませんので,
>データの取りこぼしがでます。
現在はクロスケーブルでやっています。知りませんでした。
これも初めて勉強になりました。

開発環境：１、VB6 SP3 WIN2000 SP2 P(3) 1000MHz 256MB
　　　　　２、VB6 SP3 WINME P(3) 800MHz 192MB
です。
VBのMSCOMMを使っていたんですが現在はBOCのACTIVECOMで
作り直しています。

シリアルでのファイル転送プログラムを作成しています。
あつかましいのですがソースオープンしているサイトなど
あればまた教えていただけないでしょうか

回答No.1

ykkw_2001

定石なのですが・・・・

データチェック文字（チェックディジット、ＢＣＣ、ＣＲＣetc..）を入れて見てはいかがでしょう。

たとえば・・・
分割単位（ブロック）ごとに全文字のビット毎にXOR演算した結果を最後の文字として、データにくっつけて送るのです。受信側も同じ演算をして、最後の文字と比較、違っていれば、ＮＧとして再度送信するように要求します。

大まかに流れを書くと・・
送信側は、実際のデータを送る前に、ブロック数をカウントし、受信側に送ります。
受信側は、受け取ったら、実際のデータを受付可能という意味で「第１ブロックの要求」を送信側に送ります。送信側は、第１ブロックをデータチェック文字とともに送ります。受信側は、第一ブロックが間違っていれば、再度要求、あっていれば、第２ブロック要求を送信側に送ります。これを最終ブロックまで繰り返します。
（いわゆるアプリケーション層のプロトコルという事になります）

データ文字数の情報も付けて確認すると、データの誤り率は、激減するはずです。速度は少々低下しますし、高速化の手法もいろいろあります。

ＴＣＰ／ＩＰ全盛になる以前は、これ（プロトコルとデータ誤りの低減）を考えるのが仕事だった時期もあり、仕事上では、一番楽しい時間でした。（＾＾）／

お礼

ykkw2001さん　ご回答ありがとうございます。
ここ１週間毎日悩んでいて。ちょっと兆しが見えてきました。
そこでちょっと質問なのですが、
送信側で実際のデータを送る前にブロック数をカウントして受信とありますが
分割単位（ブロック）は最適なブロック単位はどれぐらいがいいのでしょうか
データを送信したときに受信側から・・送信データがOKでしたよといった返答
が帰ってくるのを待つということですね
高速化の手法ってどんな方法なのでしょうか！

それと記述する欄を間違えてすいません。

補足

ykkw2001さん　ご回答ありがとうございます。
ここ１週間毎日悩んでいて。ちょっと兆しが見えてきました。
そこでちょっと質問なのですが、
送信側で実際のデータを送る前にブロック数をカウントして受信とありますが
分割単位（ブロック）は最適なブロック単位はどれぐらいがいいのでしょうか
データを送信したときに受信側から・・送信データがOKでしたよといった返答
が帰ってくるのを待つということですね
高速化の手法ってどんな方法なのでしょうか！