2012年02月10日

通信エラーでうまく動かない方へ

'12/2/29追記

このページのベータ版の検証結果を元に改善したバージョン1.08を公開しました。こちらのページのベータ版の公開は終了いたします。ご確認いただいた方には、この場をお借りしてお礼申し上げます。大変ありがとうございました。

これまで送信側と受信側とで同期を取りながら通信していましたが、バージョン1.08では同期を取らずに通信する機能も実装しました。これにより問題無く動作していた環境ではこれまでどおり通信し、問題が発生していた環境では状況に応じて同期を取らない通信も織り交ぜて通信することで、改善するものと考えております。

もし、「新しいバージョンでも改善しない」、「これまで問題なかったのに新しいバージョンではうまく動かなくなった」等ありましたら、このページや要望・バグ報告のページでお知らせ下さい。また、これまで問題があった方で新しいバージョンで改善された場合も、お知らせいただけると大変助かります。

'12/2/10追記

β3とβ4も追加しましたので、こちらも確認後、動作したかコメントでお知らせください。

数名の方からご指摘いただいているネットワーク通信の不具合の件ですが、いまだ当方では現象を再現できていないのですが、もしかしたら直るかもしれない修正をしたバージョンを作成しましたので、もしネットワーク通信で不具合が出ている方は、ぜひ試してみて下さい。2バージョン作成しましたので、それぞれ確認後、動作したかどうかこのページにコメントでお知らせ下さい。
※あくまで確認用のバージョンですので本番稼動では使用しないで下さい。

【ダウンロード】

VirtualPTのベータバージョンを下記からダウンロードして下さい。

VirtualPT 1.08β1
VirtualPT 1.08β2
VirtualPT 1.08β3
VirtualPT 1.08β4

【インストール】

上記のファイルをダウンロード&解凍し、既にインストール済みのVirtualPTのサービスを停止後、VirtualPT.exeを入れ替えし、サービスを起動してください。
VirtualPT_VTPT.dllも全て入れ替えてください。



domamemo at 01:13コメント(18)トラックバック(0) 
VirtualPT 

トラックバックURL

コメント一覧

18. Posted by Doma   2012年04月10日 20:45
きんた様、問題無かったとのことで、安心しました。

また何かありましたら、ご遠慮無くお問合せ下さい。
17. Posted by きんた   2012年04月10日 20:36
やってみました。エラーが出ません
VirtualPTの設定もエラー時の状態に設定しましたが
エラーが出ませんでした

お騒がせしてすいません
VirtualPTの問題ではなく
メインPCのハード的欠陥(メインメモリー不良)による不具合の可能性が大きいです。
VirtualPTとネット接続によるTV視聴のエラーと成功との間にメインメモリの交換を行っていた事を失念していました。

お騒がせしました。
16. Posted by Doma   2012年04月10日 19:28
きんた様

当方で確認したところ、リモート接続の場合、TVTestのチャンネルスキャン(地デジ)が成功しづらくなっていることを確認しました(チャンネル切り替え後の待ち時間に1秒を指定すると失敗、2秒を指定すると成功)。ただ、きんた様の現象とはおそらく違うと思います。他にはRecvPrivateの設定によってTV視聴が出来ない現象は確認できませんでした。

もう少し詳しく教えていただきたいのですが、RecvPrivate=0ならTV視聴が出来たとのことですが、BonDriver_VRPT-T.ini内のRecvPrivateを=1に変更してTVTestを再起動していただき、再度現象がでるかご確認いただけないでしょうか?その際、全ての地デジチャンネルが視聴できないのかどうか、視聴できないチャンネルは全く駄目なのか、途中から駄目になるのか、及び、使用中のTVTestのバージョンも教えてください。

お手数をお掛けしますがよろしくお願いいたします。
15. Posted by きんた   2012年04月10日 05:26
メインPC上のクライアント TVTest(32bit)下の
BonDriver_VRPT-T.dll (1.8.149.15) 注.ファイ命は適当、VRPT関係DLLはこれのみ名前を変えても変化も問題もなし

BonDriver_VRPT-T.ini 内容
-------------------------------------------
[SETTING]
HostName="192.168.0.100:12300"
Priority=0
UHFValid=1
CATVValid=0
VHFValid=0
BSValid=0
CSValid=0
ChannelMode=1
Descramble=1
RecvNULL=
RecvDuplicate=
RecvError=
RecvUnknown=
RecvDigitalTV=1
RecvOneSeg=
RecvOtherService=
RecvPrivate=
RecvLow=
RecvOtherStream=
-------------------------------------------
14. Posted by きんた   2012年04月10日 05:23
構成
PT2専用録画PC WIN7 HOME 32bit PT1x1,PT2x1 (地上波のみ)
メインPC WIN7 Pro 64bit
ルーター経由の有線LAN接続(1Gbps)

VirtualPT 1.8.537.15
設定
----------------------------------------------------
[GENERAL]
UHFValid=1
CATVValid=1
VHFValid=1
BSValid=1
CSValid=1
AutoChannelScan=1
SharememValid=1
SocketValid=1
SocketPort=12300
CATVFrequency=0
WaitPowerResume=2
[CAS]
ReaderSearch=2
ReaderList=
ECM=1
EMM=0
EMMMessage=0
[EARTHPT]
LnbPower=0
DMASize=2
GrayOff=0
UseOldSDK=0
S1Valid=0
S1Priority=0
T1Valid=1
T1Priority=0
S2Valid=0
S2Priority=0
T2Valid=1
T2Priority=0
[EARTHPT_DEVICE2/0/1]
Setting=0
LnbPower=0
DMASize=2
GrayOff=0
UseOldSDK=0
S1Valid=1
S1Priority=0
T1Valid=1
T1Priority=0
S2Valid=1
S2Priority=0
T2Valid=1
T2Priority=0
[EARTHPT_DEVICE2/2/2]
Setting=0
LnbPower=0
DMASize=2
GrayOff=0
S1Valid=1
S1Priority=0
T1Valid=1
T1Priority=0
S2Valid=1
S2Priority=0
T2Valid=1
T2Priority=0
[BONDRIVER]
Priority=0
UHFValid=1
CATVValid=0
VHFValid=0
BSValid=0
CSValid=0
ChannelMode=1
Descramble=1
RecvNULL=0
RecvDuplicate=0
RecvError=0
RecvUnknown=0
RecvDigitalTV=1
RecvOneSeg=0
RecvOtherService=0
RecvPrivate=0
RecvLow=0
RecvOtherStream=0
----------------------------------------------------
13. Posted by Doma   2012年04月09日 22:00
きんた様、VirtualPTをご利用頂きありがとうございます。

こちらでも念のため確認したい為、以下の内容を教えてもらえないでしょうか?

1.VirtualPTのバージョン
VirtualPT.exeを右クリック→プロパティ→詳細タブで確認できます。
2.VirtualPTの設定
VirtualPT.exeのあるフォルダのVirtualPT.iniの内容
3.BonDriver_VTPTのバージョン
BonDriver_VTPT_T.dllを右クリック→プロパティ→詳細タブで確認できます。
4.BonDriver_VTPTの設定内容
BonDriver_VTPT_T.dllのあるフォルダのBonDriver_VTPT_T.iniの内容
※改善前と改善後の両方をお知らせ下さい。

後、TV視聴の場合、1つのBonDriverで地デジと衛星の両方受信した方が便利かと思うのですが、地デジと衛星とを別のBonDriver(BonDriver_VTPT_T.dllとBonDriver_VTPT_S.dll)に分けて設定されていますか?
12. Posted by きんた   2012年04月09日 20:27
5 net経由でのTV視聴が出来なくて困っていました。
BonDriver_VRPT-T.iniの内容は
HostName="192.168.0.100:12300"
この部分の指定が間違っていると思っていました。
VirtualPT設定のBonDriver既定値を一部変更後無事ネット経由でのTV放送視聴が出来ました。
RecvPrivate=1 -> 0
:プライベートデータストリーム。字幕データ等

理由はわかりませんがTV映像と音声のみをBonDriver_VRPTで受け取るのがよろしい様でした。

素晴らしいものを作っていただいてありがとうございます。
わずかですが支払い手続きをしてきます。
11. Posted by Doma   2012年03月08日 21:07
通りすがりのSE様

この度はTCPの件、詳しく解説頂き誠にありがとうございました。今回の修正とは直接関係有りませんでしたが、当方で現象を再現できない難しい状況の中でモチベーションを保てたという点では、通りすがりのSE様のおかげと感じております。この場を借りてお礼申し上げます。

サイトについては、現時点で修正の予定はありませんが、今後の課題として参考にさせていただきます。
10. Posted by 通りすがりのSE   2012年03月08日 14:47
お久しぶりです。
お役に立てたのでしたら光栄です。
# 何度もしつこく書いて申し訳ありませんでした・・・(^^;


対策版をリリースとのことですが、もしかしてみんな気づいていないのでは
ないでしょうか?

私も左側の「最新記事」と「最新コメント」ばかり確認していたので、
この記事の追加部分に数日気がつきませんでした。

こんなのは私だけかもしれませんが、新しい記事とかコメントとかも
書いていただけると、RSS登録していない人にもわかりやすくてうれしいです。

私も慌ててRSS登録しましたw
ところで、コメントのRSSって無くなってしまったのでしょうか?・・・ライブドアブログ・・・

9. Posted by Doma   2012年02月22日 21:16
通りすがりのSE様、情報提供ありがとうございます。

TCPの件、大変勉強になります。私の考えが多分に古い知識であることが思い知らされました。特にリトライし続けることは、これまでの考えでは対処しきれない現象につながることに気が付きました。大変親切にご教授頂き誠にありがとうございます。
8. Posted by 通りすがりのSE   2012年02月22日 20:34
こんばんわ~

基本的にTCP自体としては、データの欠損は発生しません。
(欠損しない事がプロトコル上保証されています)
その代わり到着時間が保証されていません。
届くまでずっとリトライします。
これ以外の結末はセッションの終了(受け側や送信側のアプリが
無通信時間を計測し自発的にcloseするか、もしくはNW機器や
プロトコルスタックが処理を続行できなくなってRSTによる異常終了)
しかありません。

つまり、そのフレームを送るかセッションを切るかしかありません。
これにより、途中のデータが欠損したり、追い越しが発生しないように
なっています。

データの化けはCRCによって検知され単純にそのフレームが破棄されます。
(フレーム欠損と同じ扱いになります)

混同されがちなのですが、プロトコルスタックにデータを渡す(受け取る)際の
やり方が正しくない事が原因の不具合が多いです。
これはTCP以前の問題でAPIの呼び出し方の問題です。

ネットワーク通信は生もので、相手や回線の状態も刻一刻と変わります。
そのため約束事が多く、またOSやアプリの高度化に伴いOverlapped I/Oの
ようなちょっと複雑なやり方が増えてきたのが要因かと思います。


> ちなみに、VirtualPTでは共有メモリを通した通信にも、再送機能を実装しています。
> さすがに、こちらの機能が働くことは無いと考えていますが!

そうですね。
NW用と同じ共通ロジックを使っているとか、ロジックの不具合でデータが
破壊された事を検知できるようにチェックをしている方もいらっしゃいますよね。
メモリ自体についても、0か1かで言えば、メモリのビット化けはあり得ますが、
ECCが付いていないPCでは検知すらできませんし、メモリ上にある命令群が
正しい保証もないですし、難しいところではありますが・・・。

7. Posted by Doma   2012年02月22日 19:05
通りすがりのSE様、情報提供誠にありがとうございます。

デバッグログの件ですが、当方が自分用に使用しているものはデバッグログ機能を有しているのですが、一般公開しているものは、それをOFFにしたものを公開しております。もし次のバージョンでも改善しない場合は、デバッグログ機能がONのバージョンの公開も検討したいと思います。

TCPパケットの欠落の件ですが、私もこの場合に欠落するというような確実な事例を認識しているわけではないのですが、これまでの経験則で、通信処理を行う場合、送信したデータが必ず受信側に届くわけではないという前提の下に開発を行ってきました。TCPでもリカバリー機能を持っていたとしても全ての事例をカバーできるわけではないといった考えです。そのへんどうなのでしょうか?TCPではそこまで考慮する必要は無いのでしょうか?

ちなみに、VirtualPTでは共有メモリを通した通信にも、再送機能を実装しています。さすがに、こちらの機能が働くことは無いと考えていますが!
6. Posted by 通りすがりのSE   2012年02月22日 13:42
Overlapped I/Oだったんですね。
失礼しました。
確かにOverlapped I/OのWSAsendは全サイズ渡した後に処理完了です。

ここまで来るとロジックとかも絡んでくるので、デバッグ用にログを出力してしまうのが
早いかもしれませんね。
・APIのエラー(API名,エラーコード,データ)
・受信判定のNG(判定NG理由,受信データ,組み立てバッファの内容等々)
・応答返信データのタイムアウト(直前に送ったデータ等々)
・再送の実施(送り直したデータ等々)

動きが見えれば解析しやすいと思いますし・・・
正常ルート時には何も出力しないようにすればパフォーマンス等への影響も少ないでしょう。

事象が発生しているユーザーさんの中にwireshark使える人がいれば、
通信内容をキャプチャーしてもらうとより良いと思います。


> TCPプロトコル自体に再送機能があることは認識しているのですが、パケットの欠落は
> 発生しえると認識しております。

との事ですが、確かに物理層とかでフレームが欠損する事がありますが、TCPレイヤで
シーケンス番号により検知&再送されますので、アプリレベルで対応というのはあまり
体験した事も聞いた事がないのですが・・・
どのような場合に発生するのでしょうか?
後学のために教えてください。
似たような話で、データ化けしたときにCRCチェックをすり抜ける可能性がごく僅かでも
あるので、アプリ側でもCRCやハッシュでチェックすべきだという話は聞いた事があります。


5. Posted by Doma   2012年02月22日 09:34
- 2/2ページ -

なお、先日公開したベータバージョンの検証から、VirtualPTではストリームデータ(放送データ)を送信した場合、1ブロック毎にデータ受信状況を知らせる返信を待つのですが(ストリームデータの欠落、応答返信データの欠落も考えられますので単純に待っている訳では有りませんが)、この応答が当方の想定時間(最も負荷が高いであろうBSハイビジョン放送の場合で13ms)以内に来ないと、データを掃けきれなくなります。恐らく環境によって返信応答が当方の想定以上に掛かっていることが問題点ではないかと考えております。

先日検証頂いた方の返信に、今までの方法・改善した方法を選択できるような修正をするようなコメントをしたのですが、現在、返信応答が想定以上に掛かっているか自動で判別し改善した手段に自動で切り替わるようなバージョンを作成中です。このバージョンで、これまで問題なかった方はこれまでどおり、問題が起きていた方のみに修正したコードが働き(再送機能は働かないが)、不具合が改善されるのではないかと考えております。まもなく公開できると思います。

setsockoptの件、もしそこに問題があるのであれば現象が直ぐに発生すると思います。数十秒は問題ないことから今回の不具合とは関係ないのではと思います。もし新しいバージョンでも改善しない場合、その辺の調査ベータを作成してみようと思います。

>それと、ネットワーク越しの録画、私はやるかも・・・・(^^;
大変貴重なご意見ありがとうございます。参考にさせていただきます。
4. Posted by Doma   2012年02月22日 09:33
通りすがりのSE様、情報提供頂き誠にありがとうございます。

- 1/2ページ -

TCPプロトコル自体に再送機能があることは認識しているのですが、パケットの欠落は発生しえると認識しております。なのでVirtualPTでの再送機能は全く不必要な物とは言えないと思います。

今回送信側の修正点としてご指摘頂いた、送信時に一部だけが受付けられる場合の対処法ですが、当方の処理ではオーバーラップ化ソケットを使用しておりましたので、「全てのデータを受付けた」、「全てのデータの受付が即座に完了しなかったので、完了したらイベントをセットして知らせる」、「その他のエラー」といった状態しか発生せず、一部だけが受付けられたといった状態は発生しない事が分かりました。その辺のことを直ぐに明確に回答できれば良かったのですが、1年以上前に書いたコードで記憶があいまいになっていたこともあり、何度もご心配をお掛けしてしまい申し訳ありませんでした。大変感謝しております。

受信側の修正点としてご指摘頂いた点は、既にそのようになっております。
3. Posted by 通りすがりのSE   2012年02月22日 06:29
お久しぶりです。
くどいようで申し訳ありませんが、もう一度書き込みさせてください。

TCPの場合、再送処理自体は下位レイヤーが行いますので、アプリ側で
再送する必要はありません。
ですので、送信バッファに送れたものは(下位レイヤーが再送含めて
処理してくれるので)相手側にも届くと考え、
「続きから送信する」のが基本的な処理の仕方になります。
また、受信側は続きが後から来るかもしれないので、所定のサイズを
受け取るまで待つ必要があります。

以前書き込みしていただいたプロトコル&処理なのであれば、下記2ヶ所を
修正していただければ改善されるものと思います。

送信側:送信バッファに全部を受け取ってもらえなかったときに、
   :丸ごと再送するのではなく、受け取ってもらえなかった残りだけを
   :再度送るようにします。
   :またWSASendの一回の呼び出しで送る最大データサイズが判っているなら
   :setsockoptでソケット送信バッファ(一番アプリよりの送信バッファ)
   :のサイズをこの最大サイズ+1Byte以上に設定すると効率がよくなります。
   :大きすぎるサイズを指定するとエラーになりますが・・・。

受信側:データ終端の区切り文字が受信されるまで待つ(受信し続ける)

ネットワーク上での再送は下位レイヤーに任せ、シンプルに窓口である
送信バッファにきちんと重複や欠損なく渡す事だけを考えれば、問題なく
送信できると思います。

それと、ネットワーク越しの録画、私はやるかも・・・・(^^;
2. Posted by Doma   2012年02月17日 21:56
inf様、ご協力頂き誠にありがとうございます。

β2で最も改善したとのことですが、そのバージョンは、通信エラー時の再送機能を無効にする代わりに、回線をもっと効率よく使用するように改善したものです。

コメント頂いた方々は皆、有線LANであったことから、当方の無線LAN(実効帯域24Mbps)環境でも問題なく使用できていたので、有線では帯域不足はまず無いだろうと考えておりましたが、検証頂いた結果から推察すると、VirtualPTのやり方では帯域を効率的に使用できずに帯域不足状態となる場合があるように思われます。

TCP-IP経由で使う場合、おそらく視聴のみで録画で使用することはまず無いであろとすると、多少のドロップはある程度許容できるものと考えられます。なので、β2の機能もオプションで選択出来るようにしたバージョンをリリースしたいと思います。

ただ、β2はあくまで簡易に修正したものですので、もしかしたら正式リリースの前に再度ベータを公開する可能性がありますのでご了承下さい。
1. Posted by inf   2012年02月17日 18:12
早速検証しました。

VirtualPT 1.08β1 →×:ビットレート低下変わらず
VirtualPT 1.08β2 →△:他より大きく改善。しかしたまにコマ落ちする。
VirtualPT 1.08β3 →×:ビットレート低下変わらず
VirtualPT 1.08β4 →×:ビットレート低下するが1,3よりはマシ

以下、環境
Server側
OS:Windows2008R2 Enterpirse
VirtualPT x64 + TvRock 32bit + BonDriver 32bit + TvTest 32bit

Client側視聴環境
OS:Windows7 Enterprise (64bit)
TvTest 32bit + BonDriver 32bit

ということでβ2が一番実用に耐えました。
他よりビットレートの低下が発生する確率が大分減りましたが、
やはりコマ落ちが発生します。
正式版、他のβ版と比べてコマ落ちがずっと続くというわけではないので、
なんとか視聴できる状態でした。

録画は問題無いので、現在は正式公開版に戻しました。
不具合の参考になれば幸いです。

コメントする

名前
 
  絵文字
 
 

プロフィール

Doma

記事検索
最新コメント
最新トラックバック
タグクラウド
  • ライブドアブログ