Microsoft.ServiceModel.WebSockets

今回のネタは、わたしは実のところWindowsやLightSwitchにあまり詳しくないので、より楽観的な話が期待できる部分があるかもしれない。一応。

• • • -

MIX11で出てきたネタを取り上げてみるよ。
http://html5labs.interoperabilitybridges.com/prototypes/available-for-download/websockets

正直コレはproof of conceptに過ぎず、System.ServiceModel.WebSockets等の名前になって.NET Frameworkに組み込めるようになってWebアプリで実用化される頃には、HTTPサーバがごそっと変わっていると思う。というのは、サーバサイドは80ポートでHTTPサーバと統合されている方が望ましいからだ。

IISが80ポートで稼働していると、同じポートを共有できない。でもIISが大幅に更新されるのはきっとWindows 8(?)以降だろうから、Visual Studioで作成できる「WCFサービス」アプリケーションで、そのようなスマートなWebSockets統合が出てくるのはしばらく先になるだろう。その観点では、むしろLightSwitchの組み込みHTTPサーバが先に対応する可能性はある。でもあれがWindowsのHttpListenerを使っているなら、それもやっぱり厳しいかもしれない。

上記のMicrosoft.ServiceModel.WebSockets.dllを使ってサービスを書いてみたのだけど、URI Schemeがwsでないと拒否されるので、BasicHttpBinding等とは別にservice endpointを作る必要がありそうだ。という前提でwsとhttpでポートを共有すると、このような感じのコードになると思われるけど、やはり上記の実装ではTCPソケットを同じポートで別にリッスンしようとしてエラーになる。

HttpListenerを拡張すれば問題ないんじゃないかと思うけど、.NETのHttpListenerはHTTP.SYSに依存するので、やっぱりOSレベルで変わらないとダメかも。

…と先行きの見えない話を書いたが、実のところポートを共有できないなんていうのは些細な問題で、WebSocketsの旧仕様のようにport 81とかでサーバを立ち上げれば、もちろん問題ない。特定のポート以外をブロックしている企業の中からアクセスすることは出来ないかもしれないけど（そういうところで問題が生じないようにWebSockets仕様はport 80に統合したんだろうと思う）。

個人的にHttpListenerを改造する方向で作ろうとしたことがあるのだけど、それはWSの仕様がHTTPに近く、HTTPサーバをゆるやかに拡張することで実現できそうに見えたからだ。出来上がっていないから実際のところどうだかは何とも言えないけど。

ちなみに、Manosを使えばWebSocketsにネイティブで対応している（はずな）ので、未来を待つ必要は無い（はず）。