UDPでの再送

[めいこ]

通常、プロトコル部分でIPヘッダとUDPヘッダが自動的に付加され、チェックコードが付与されますよね？
受け取り側のプロトコル部分でチェックコードを計算→正しければペイロードをプログラム側に渡す→間違っていたら、そのパケットは破棄。
これがUDPの流れだと思うのですが、この破棄を検知し、再送を促すことは可能なのでしょうか？

Skypeの画面共有のようなことをやりたいので、TCPではなく高速なUDPを使いたいのですが、データの破損が心配です。
どのような処理をすれば安心できますか？

[softya（ソフト屋)]

安心したかったらTCP/IPだと思います。
Skypeだとパケットが部分欠損しても大丈夫なように組まれているはずです。

[めいこ]

安心したかったらTCP/IPだと思います。
Skypeだとパケットが部分欠損しても大丈夫なように組まれているはずです。

破損しても大丈夫な組み方とはどんな組み方でしょうか？
公開はされていないでしょうが、ソフト屋さんが作るとすれば、どのようにしますか？
個人で作成するには難しいレベルでしょうか？

[softya（ソフト屋)]

それがSkypeのキモですからね。
私もストリーム系には詳しくないですし、大学院卒の博士号持ちや大学の教授レベルが考えるようなデータ欠損を許す映像ストリームなどのプロトコルを発案する才能無いです。
そういう事に情熱を傾けたこともないので断片的な情報を知るのみです。

ここにあるような情報を片っぱしから調べる（英語サイトも含めて）ぐらいしか手がないかなって思います。
「Between Winds and Clouds » Skype / Google Talkの仕組み」
http://drag0n.fam.cx/?p=574

[h2so5]

RUDPというプロトコルが参考になるかもしれません。再送機能付きのUDPのようなものです。
https://ja.wikipedia.org/wiki/Reliable_ ... m_Protocol

[めいこ]

それがSkypeのキモですからね。
私もストリーム系には詳しくないですし、大学院卒の博士号持ちや大学の教授レベルが考えるようなデータ欠損を許す映像ストリームなどのプロトコルを発案する才能無いです。
そういう事に情熱を傾けたこともないので断片的な情報を知るのみです。

ここにあるような情報を片っぱしから調べる（英語サイトも含めて）ぐらいしか手がないかなって思います。
「Between Winds and Clouds » Skype / Google Talkの仕組み」
http://drag0n.fam.cx/?p=574

そうですか・・・
英語サイトも結構見たのですが・・・

[めいこ]

RUDPというプロトコルが参考になるかもしれません。再送機能付きのUDPのようなものです。
https://ja.wikipedia.org/wiki/Reliable_ ... m_Protocol

RUDP。これは知りませんでした。
Windowsの環境では使えるのでしょうか？

[h2so5]

Windowsの環境では使えるのでしょうか？

ただのプロトコルですから実装すれば使えますよ。
データを再送するとそのぶんだけどんどん遅延が大きくなるので、リアルタイムの画面共有ではRUDPはあんまり向いていないかもしれません。

データの欠損に関しては、過去のデータから予測するとか周囲の画素から補完するとかして不自然に見えないようにすればいいんじゃないでしょうか。フレームレートの安定性を重視するのか、画質を重視するのかとかで方法は変わってくるはずなので一概には言えません。

アルゴリズムの研究が目的ではなくアプリケーションを作りたいだけなら、FFmpegなどストリーミング機能のあるライブラリを使えばいいと思います。VNC派生ソフトでオープンソースなものがあるのでそれも参考になるかもしれません。
http://sourceforge.net/projects/tigervnc/