lisz-works

技術と興味の集合体

通信を扱うプログラムって難しいのな。って話

【スポンサーリンク】

ラップトップを操作する人

最近、通信を扱うプログラムの作成は、難しいということを改めて体感したお話。

通信関連はあまり詳しくなかったので、それなりにわかる人から聞いたりしつつで感じたこと。

UDP通信

仕事ではもっぱらUDPを使っています。

UDPとは

User Datagram Protocol(ユーザ データグラム プロトコル、UDP(ユーディーピー))は、主にインターネットで使用されるインターネット・プロトコル・スイートの中核プロトコルの一つ。
引用:https://ja.wikipedia.org/wiki/User_Datagram_Protocol))

データグラムとは

データグラム データグラム(英語: datagram)は、配送成功・到達時間・到達順序がネットワークサービスによって保証されることがないパケット交換網における基本転送単位である。
引用:https://ja.wikipedia.org/wiki/データグラム

つまり、ユーザ(作り手)側が規則を決めてあげないと、正常な通信が行えません。

一般的には、動画や音声通話など、途中のデータが欠損しても問題ないようなものに使用されます。

受信してデータを

  • どうとるか
  • どうすてるか
  • どう見るか

これらを、ちゃんと決めないといけないし、事前にルールをきちんと決めないといけない。

UDPでなく、TCPだとしても

  • 受信したデータのサイズはいくつか?
  • データがきちんと頭から入っているか?
  • 1データ分以上データが入っているか?

などのような、ことをチェックし、ルールに乗っ取って処理してあげないといけない。

とにかく「受信したデータがどのような状態か?」というのは、不確定だからきちんと考慮してあげる必要がある。

事前に「このようなデータでやり取りしよう!」と決めても、必ずしもクリーンな状態で先頭からデータが乗り、想定したサイズが乗っかってくるとは限らない。

ローカルでの通信でない場合、それはさらに顕著になってしまう。

受信サイズは固定長ではない

「このサイズでくるはず」という前提で作ってしまった場合、データが1つでもずれた時点で終わりを迎えます。

例えば環境やネットワーク状況の問題で、1Byte分が次のパケットの先頭についてしまった場合。

  • 1パケット目の最終データは0として取り扱われる。
  • 2パケット目の最初のデータが、想定と異なるデータとなる。

これによってこのデータは崩壊します。

TCPも同じよう

TCPもデータ運搬の確実性を担保するだけらしい。

なので1回の伝送で送られるデータサイズは不確定だそうです。

そのためこれも同じく、受信データの構築処理とかで、同様に考慮して作らないとダメらしい。

TCPはある程度こういうことを勝手に管理してくれるものかと思っていた……

あとがき

通信を行うプログラムについてでした。

戒めと備忘録を兼ねて。

これらに関連することで躓いたけど、解決方法がよくわからなかったというのが凄く痛かった。
めっちゃ時間かかったし。

ちょっとネットワーク系勉強しようかなとか思っちゃいましたよね……