"リアルタイム Web" に関するプラクティスのアウトプット - Block Rockin’ Codes
追記 11/12/26 MLのスレッドへのリンクが間違っていたので修正。 introduction WebSocket なんかをつかって、従来のステートレスな処理以外に、コネクションを継続するステートフルな処理が可能になりました。 これを利用すると、これまで実装が難しかったリアルタイムな表現を Web に持ち込むことができます。 そして、 WebSocket を用いたプログラムを作成する上で、Node.js と Socket.IO を用いる方法について、 今年はこのブログでも何度か紹介してきました。 今日は今年一年の集大成として、自分が色々試しながら得たリアルタイム Web に関する知識、技術などを、 ここにまとめてアウトプットしたいと思います。 今回お話しするのは、 東京Node学園 3時限目 : ATND で発表した下記内容の抜粋です。 Node Academy | "About Sl
Socket.IOでメッセージが届いたことを確認する - Qiita
WebSocket使ってると、クライアントからサーバーにメッセージ送って、届いたのがはっきりしてから何かしたいことがあったりします。WebSocketの仕様その物にはそういう機能は無いようですが、Socket.IOにはそういう機能があったのでこれが使えました。 （低レベルの話を期待していた方、済みません） ドキュメントに書いてあることそのままではあるんですが：Sending and getting data (acknowledgements) Socket.IOのacknowledgements機能 emitするクライアント側のコード、サーバー側のonで待ち受けるブロックのコード、のそれぞれでコールバック関数を登録することで、クライアントからのメッセージが届いた時の処理を書けます。処理を書けるということは、届いたことが確認できるということです。 // クライアント側 var ws = i
Socket.ioで作ったWebSocketサーバをELBでロードバランスする - Qiita
課題 現在、作っているサービスではsocket.ioを使って作ったWebSocketサーバをELB経由で使っています。 開発環境はELB配下にEC2が1台で、本番環境は複数台です。 これ、どちらも正しく動いているように見えていたんですが、最近セットアップした本番環境の方でWebSocketへのUpgradeがうまくいっておらず、pollingで動いていることに今日気がつきました。 サービスとしてはまぁ一応問題はないんですが、WebSocketで動いていると思っていたものが実はPollingだったというのはわりかし衝撃です。 原因 なんでやねんと思ってググるとわりと簡単に原因に行き当たりました。公式ドキュメントで思いっきり説明されています。 日本語だとこの辺でが参考になります。 Express / Socket.IO をスケールアウトしてみよう Socket.IO or WebSocket
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
