ASP.NET SignalRを知る：特集：ASP.NET SignalR入門（前編）（5/5 ページ）

「One ASP.NET」というビジョンの下、ASP.NETが大きく進化している。「SignalR」とは何か？ 今までにない「楽しさ」を味わおう。

[芝村達郎，著]

WebSocketとの関係

　SignalRはWindows Server 2012から搭載されたIIS 8と.NET Framework 4.5を組み合わせることで、トランスポートとしてWebSocketが利用可能となる。

　開発環境であってもIIS 8.0 Expressと.NET Framework 4.5の組み合わせの場合、ブラウザ側が対応していれば、WebSocketが自動的に利用されるようになっている。そのため、FiddlerやGoogle Chromeを利用することで、どのようなデータが送受信されているのかを簡単に確認することが可能だ。次の画面は、実際にChromeでデータの送受信内容を確認している例だ。

Chromeを利用して、WebSocket通信をキャプチャ表示

　復習となってしまうが、WebSocketはServer-Sent EventsやAjax Long-pollingのようなHTTPをベースとしたトランスポートとは異なり、もともとリアルタイム通信用に設計されており双方向の通信が可能となっているため、レイテンシの少なさやリソースの使用効率の面で優れている。

　しかしながら、注意点としてWebSocketはHTTPのようにリクエストに対して、必ずレスポンスが返されることを前提としたプロトコルではないことを意識しておくことが挙げられる。つまり、WebSocketで動いている場合にはHttpContextオブジェクト（System.Web名前空間）は作成されるのだが、そのResponseプロパティには操作不可能なオブジェクトがセットされている。

　実際にSignalRで次のサンプル・コードのようにHttpContext.Current.Responseプロパティを触ろうとすると、WebSocketの場合のみ例外が投げられる。

[HubName("echo")]
public class EchoHub : Hub
{
  public void Send(string text)
  {
    // WebSocketではResponseプロパティを操作できないため、例外が投げられる
    HttpContext.Current.Response.SetCookie(new HttpCookie("session")
    {
      Value = "sample value"
    });

    Clients.All.Receive(text);
  }
}

SignalRではHttpContextオブジェクトに直接触ることは原則避けるべきである

　WebSocket以外のトランスポートでは例外が投げられないため、開発環境では動作していたが別のユーザーが使用した場合に動作しないこともあり得るので注意が必要だ。開発ではHttpContextオブジェクトになるべく触らないように設計し、触る必要があったとしても最低限にすべきだろう。

　先ほどの繰り返しになるが、SignalRでWebSocketを有効にするためにはIIS 8と.NET 4.5の両方が必要だ。つまり、現在は.NET 4.5は使えるがIIS 8は使えないWindows Azure Webサイトでは、WebSocketが有効にはならない。Windows Azure上でSignalRをWebSocketで動かすには、クラウド・サービスでWindows Server 2012のゲストOSを指定して使うしかないので、注意していただきたい。

---

　本稿では、SignalRの概要について説明をした。SignalRを使うと、ほんのわずかなコードを記述するだけで、サーバとクライアントの間でリアルタイム性を持った双方向通信を実現するサービスやWebアプリを作成できる。ここで作成したチャット的なアプリだけではなく、リアルタイムに情報が更新されることに大きな意味のあるアプリを開発しようという場合、SignalRには大きな価値があるかもしれない。

　次回は実際にアプリを開発する上で非常に重要となるグループ化や認証、そしてクラウド・サービスを利用する上で非常に重要となるスケールアウトについて解説を行う予定だ。

「特集：ASP.NET SignalR入門」