開発者が語る、無線技術についてや製品開発の秘話、技術者向け情報、新しく興味深い話題、サイレックスが提供するサービスや現状などの話題などを配信していきます。ペアで使われる技術要素として「WebSocket」というキーワードがよく引っかかってきます。ついて簡単に紹介します。回線上で任意長・任意フォーマットデータの双方向通信を実現するものです。非常によく似ています。Google!)ですが、コンピュータの世界では「よくあること」です。筆頭とするスクリプト系言語から使うために開発されています。回線で通信しているようなプログラミングを行うことができます。与えるものではないことに注意してください。代わりに使うことでポートスキャンやプロキシ偽装などのハッキングに悪用されないことは設計上の一大懸念となっており、これを防ぐために幾つか奇妙とも思える仕様が導入されています(※註)。※註:「Sec-WebSocket-Key」や「ペイロードマスク」などですが、詳細には触れません。ネット上での文書共有のために開発されました。基本動作原理はリクエスト(クライアント/ブラウザ)~レスポンス(サーバ)の往復形式です。用いてデータ長不定のまま通信を始めることもできますが、サーバ→クライアント方向の通信はあくまでリクエストに対するレスポンスとしてしか送信できず、リクエストが完結するまでレスポンスは返せません。任意タイミングで任意データをサーバ→クライアント方向に流すことが原則としてできません。秒間隔などでサーバに送ってレスポンスを促すポーリングという実装が使われたりしましたが、どうしても反応時間に上限がありますし、反応時間を早めようとポーリング間隔を縮めれば通信効率は悪化する相克があります。ドラフトで叩かれまくって仕様が二転三転し、数次にわたる改訂途中のドラフトに基づいた実装が世に出てしまったので、それら過渡ドラフトバージョンまで含めた仕様を全て網羅するのは大変になってしまっています。ファイヤウォールといった壁だらけになっていることが最大の理由だと思います。以外の新ポートを開けさせる)ことは現実的とは思えません。いうベースがあるのだから、それに相乗りするのが現実的ということになります。ようなものを乗せる」という、技術的には奇形ともいえる方法論を選択することになってしまいました。これもやっぱり「よくあること」です(※註)。流す」なんて無駄なことが日常的に行われたりしています。ついても日本語で豊富な情報を得ることができるので、このブログでは動作シーケンスやらフォーマットの詳細には踏み込みません。基本的な動作原理について述べるにとどめます。いうヘッダも付けられる)が合意されます。Stream)」ではなく、簡単なヘッダが付いてデータ単位長が示されます。おけるメッセージ/レコードと少し似ています。じたい屋上屋根を重ねたような経緯で開発されたものですから仕方ないです。拡張レングスフィールドが付加されるルールになっています。規則の可変長レングスエンコーディングに似ていないこともありません。年も経つと再び「やっぱり可変長エンコードのほうが効率的」と評価されるなんて「人類はいったい何をやっているんだ」という気になりますが、これも「よくあること」です。技術の方法論には絶対善も絶対悪もなく、それが使用される環境との兼ね合いによって評価されるもので、そして環境は常に変化し続けるものだからです。似て非なるLengthエンコードが3種類もあるとか、いい加減にして欲しいとは思います。=6バイトのときヘッダ全長がちょうど64bit=8バイトに収まるようになっています。アドレスのタイプ/長さ」を識別するフィールドが無く、例えばIEEE802.15.4などで使われている64bitのEUI-64アドレスを送ろうとすると2バイトはみ出し64bit単位に切り上げてヘッダ長は2x64bit=16バイトになり、しかもアドレス長/パディング長はどこにも示されないので、プロトコルの枠外(リンク層のドライバディスクリプタなど)からアドレス長を参照するというあまり「美しくない」仕様になってしまいます。境界に「綺麗に」収めようとし過ぎた無理がある仕様だと私は思っています。現状を如実に示していると思います。回反復送信するなんて「無駄なこと」はやらなくて済む筈だったんですよね。置き換えてゆくでしょう。若きエンジニアたちが託した「未来に撒いた種」は、結局芽を吹かずじまいでした。年後にはどうなっているかわかりません。使うのが常識じゃん!」と言っているかも知れません。技術の最適解は環境によって変化し続けるものですから。個人情報の取り扱いについて。