スポンサード リンク

T.Ishii's Software Library

HTML5 レトロ風ゲーム館

無料ブログはココログ

« テレビ電話も暗号化 | トップページ | 迷惑メールが100/日越え »

超低速での通信テストとか

今は、Mirror-DTCのシェアウェア化を行うフェーズで、今週はリリースに向けた仕上げ作業を行っていたのだが、大体、完了した。ただし、まだ、エラー処理関連の実装が甘いので、あと数日は、アリガチなエラー状況を作りだしつつ、テストとその結果を受けた改良を行う。

このブログを真面目に見ている人なら判っている筈なのだが、作者的には、労多くして益少なしな作業は行わない様に注意している。

つまり、1万人いるユーザーの中で、数人の環境でしか発生しない様な不具合については、発生したとしても、それは仕様、という事にして、その不具合を修正する様な事はしない様に注意している訳なのだが、1万人のユーザーの中で、1,000人程度が不具合を経験する事になるとすると、そういう不具合は修正しようとはする訳だ。

と、いう事で、作者的にも、アリガチなエラーについては、発生しない様に出来るのならそうするし、発生するのは致し方ない、というモノについては、発生した場合の対応方法について鑑みる訳だ。

で、今日は、昨日書いていた様に、今回開発したテレビ電話ソフトである所のTiHotLine Liteも、今回開発した中継サーバーに接続して利用できる様にしたのだが、当然の事ながら、TiHotLineはMirror-DTCとは接続できない。

これは何を意味するのか、というと、中継サーバーにはMirror-DTCサーバーか、TiHotLineが接続して相手からの接続を待てる格好になったのだが、例えば、中継サーバーにTiHotLineを接続して相手からの接続を待っている時に、Mirror-DTCクライアントから接続されてしまう、というのはアリガチな問題になる訳だ。

何故なら、今回、TiHotLineを開発したのは、Mirror-DTC ServerからClientに接続する利用形態では、サーバー側にいる人物とクライアント側にいる人物は別人である事を想定する訳なので、Mirror-DTC接続する場合には、接続の準備用の会話だとか接続中の作業に関する会話なんかが行えないと辛いからだ。

つまり、TiHotLineとMirror-DTCは同時に使われる事は普通にある筈で、かつ、Mirror-DTCが中継サーバーを利用しなければならないシチュエーションでは、TiHotLineについても、中継サーバー経由で接続する必要性がある筈な訳だ。

なので、中継サーバーには、予め、Mirror-DTCサーバーと、TiHotLineを接続して待機させておいて、そこに、Mirror-DTCクライアントと通話相手のTiHotLineを接続する格好になるのだが、その時に、接続するポート番号を間違えば、前述の様なエラーケースが発生する事になる訳だ。

と、いう事で、今日は、そういった間違った接続を行おうとした場合に、普通にメッセージを表示して接続が失敗する事を確認していたのだが、実際の所、最初の段階では、接続は失敗しているのに、メッセージ表示等は発生せず、実質的には、ストール状態になったりもしていた。

何故、そうなるのか、というと、仮面ライダーは変身ポーズ中には本郷猛でも仮面ライダーでもないので、どちらの力も発揮できないからなのだが、まあ、そんな感じになってしまう事を発見できれば、対応方法はいくらでもある訳なので、今日は、ちゃんとエラー表示して接続を失敗させられる様に変更を入れた訳だ。

で、TiHotLine Liteも、これで、中継サーバー経由で接続して利用できる様になったのだが、今回開発した中継サーバーには、転送速度に制限を入れられる機能を実装してある訳だ。

なので、作者的には、早速、その最低設定である所の、0.1Mbpsに制限しつつ、TiHotLineを使った場合、どうなるのかを確認してみた訳だ。

その結果としては、TiHotLineでは、Mirror-DTCでは行っているエラー処理の一部を端折っていた事もあり、結構、酷い状況になったのだが、その原因は、転送速度が遅すぎて、転送タイムアウトが発生したので、異常なデータ転送が発生する事になった。

何故なら、タイムアウトを検出しているのは、TiHotLineで、OSのTCP/IP処理では、転送を継続しようとしていたので、エラーリトライ等により、転送データが多重に転送されたりしてしまったからだ。

Mirror-DTCの場合、そういうパケットは破棄されるのだが、TiHotLineの場合、パケットチェックは端折っているので、同じデータが複数回転送されたりした訳だ。

もっとも、TiHotLineでエラーチェックを端折っているのは、それらのデータはビデオ映像と音声再生でしか使われないので、問題が発生しても、ビデオ映像の画像が崩れたり、音声にノイズが乗ったりするだけだからだ。

しかしまあ、それはそれで見苦しいので、今日は、タイムアウト時間を十分に伸ばして、通常は、上記の様な状況が発生しない様にしたりした。

理論上、全く問題が発生しない様にしたければ、Mirror-DTC並の作り込みが必要になるのだが、TiHotLineについては、そこまでしなくても・・・、という事にした訳だ。

と、いう事で、今日は、中継サーバーを利用できる様にしただけではなく、0.1Mbpsの速度制限を付けた場合にも、TiHotLineがそれらしく動作する様にした訳なのだが、速度制限が0.1Mbpsの場合、ビデオ映像は数秒に1回くらいしか変化しない。

また、音声についても、最高音質は、普通の環境なら、44100Hzx2chx4Bit=0.34Mbpsになるので、0.1Mbpsではマトモに転送できない。

つまり音声についても途切れ途切れになる訳なのだが、TiHotLineでは、音声品質を落とした転送も可能で、デフォルトの中音質なら、22050Hzx1chx4Bit=0.088Mbpsなので、音声だけなら、0.1Mbpsの制限をつけても、普通に転送可能だった。

更に、低音質にすれば、8000Hzx1chx4Bitなので、必要となる帯域は0.03Mbps程度になるので、映像用にも帯域を少しは残せる。

映像についても、低品質にすると、解像度は160x120になるので、それなりに転送可能にはなるのだが、0.1Mbpsでは、やはり辛い。

しかしまあ、帯域が0.3Mbpsもあれば、TiHotLineの場合、低品質に設定しておけば、音声付きの映像も、普通に、動画として送信可能ではある様だ。

« テレビ電話も暗号化 | トップページ | 迷惑メールが100/日越え »

トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/534482/67042408

この記事へのトラックバック一覧です: 超低速での通信テストとか:

« テレビ電話も暗号化 | トップページ | 迷惑メールが100/日越え »

2018年10月
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31      

広告

プライバシーポリシー

  • 当サイトでは、第三者配信による広告(Google Adsense)サービスを利用しています。

    Google を含む第三者配信事業者は、Cookie を使用して、ユーザーのウェブサイトでの閲覧履歴に基づく広告を配信します。 Google 広告 Cookie を使用することにより、Google や Google のパートナーは当サイトや他のサイトへのアクセス情報に基づく広告をユーザーに表示できます。

    収集された情報がGoogleによってどの様に使用されるか、収集される情報をユーザーが管理する方法については、以下のリンクを参照下さい。

    ポリシーと規約 - Google