TL;DR 2016年8月にAWSのLoad Balancerが WebSocketに対応した スムーズすぎて心配になるくらい簡単に導入できる 「うまい、はやい、やすい」ので、導入しない理由はないと思う ALB Release! 巷では長らく噂になっていた、新しいAWSのLoad Balancer。 先月2016年8月11日についにリリースされた。待望のL7対応だ。 個人的に魅力の一つだったのはWebSocket対応。 従来のELBではWebSocket通信を終端できなかったため、 WebSocket通信の負荷分散/バランシングを行ったりSSL/TLS化する場合、 自前でバランシングする仕組みを実装したり、Nginxを前段に配置するなどちょっとした工夫が必要だった。 AWSのLoad BalancerがWebSocketサポートしてくれるのであれば、この設計構築および運用をアウトソース出来
※2012/01/09 追記 続きもあるよ あらすじ 先月晴れてsocket.ioクラスタがデビュー。 しかし想定していたよりxhr-polling接続が多くてフガフガな状況に。 こりゃxhr-pollingの性能評価もしとくべきだったなーと思いを馳せるアルパカ。 そこでsocket.io-clientでベンチマークを走らせたのだが websocketと時と異なりコネクションがすぐに詰まるという自体が発生…！ アルパカ大明神の運命やいかに！？ 現象 socket.io-clientでxhr-pollingのコネクション貼りまくると5コネクションで詰まる。 時間が経つとその内ヌルッと進む。 chromeやfirefoxでも同様。 調査 様々なクライアントから実行しても同様の状況が見られたため サーバの問題と断定しサーバ調べる。 しかしコード追ったりトレース取ったりしてもまったく原因わからず…
var io = require('socket.io'); socket.on('message', function(data) { // クライアントから'message'でdataを受け取った際のハンドラ io.emit('message', message); // すべてのクライアントへ送信 }); var socket = io(SERVER_HOST); // サーバーと接続 // 送信処理 $('form').submit(function(){ // formのsubmitが押された時 socket.emit('message', $('#input').val()); // サーバーへ'message'として#inputの内容を送信 return false; }); // 受信処理 socket.on('message', function(data) { //'m
Socket.IO開発時に役立つツール4選とroom、namespaceライブラリの使い方：Socket.IOで始めるWebSocket超入門（終）（1/3 ページ） 本連載では、WebSocketを扱えるNode.jsのライブラリ「Socket.IO」の使い方について解説します。今回は、チャットアプリ開発を進めながら、「room」「namespace」ライブラリの使い方について説明し、最後に開発時に役立つツールを4つ紹介します。 本連載「Socket.IOで始めるWebSocket超入門」では、WebSocketを扱うことができるNode.jsのライブラリ「Socket.IO」を使って、サンプルアプリケーションを構築していきます。 具体的には、チャットを題材とし、送受信されるメッセージ内容が即時反映されるリアルタイムかつ双方向なWebアプリケーションの構築を目標とします。さらに構築の中で
[email protected]で大きくアーキテクチャが変わるみたいなので調べてみました。 binaryをサポートしたことで, 例えば node-canvas でサーバ側で rendering した canvasをbinary で効率良く送信もできるとの事。 [email protected]の構成が以下です。 /lib$ tree . ├── logger.js ├── manager.js ├── namespace.js ├── parser.js ├── socket.io.js ├── socket.js ├── static.js ├── store.js ├── stores │ ├── memory.js │ └── redis.js ├── transport.js ├── transports │ ├── flashsocket.js │ ├── htmlfile.j
最近socket.ioがメジャーバージョンになって少しかわって 今まで io.sockets.socket(id).json.emit('msg', send_msg); みたいな感じでかけてたのですがsockets (namespace)がsocketメソッドを持たなくなってて、「 あれ特定ユーザ探す方法なくね」って思ってたんだけどドキュメントよんでたら Each Socket in Socket.IO is identified by a random, unguessable, unique identifier Socket#id. > For your convenience, each socket automatically joins a room identified by this id. This makes it easy to broadcast messages
Socket.IOのnamespaceとroomの使い分けに迷ったのですが、stackoverflowにぴったりの回答がありました。 http://stackoverflow.com/questions/10930286/socket-io-rooms-or-namespacing This is what namespaces and rooms have in common (socket.io v0.9.8): Both namespaces (io.of('/nsp')) and rooms (socket.join('room')) are created on the server side Multiple namespaces and multiple rooms share the same (WebSocket) connection The server will t
とあるサービスに「チャット機能」を追加しようという話になり、急ピッチで仕組みを用意することになった。 仕様/要件はふわっとしているものの、 2週間後にはリリースというケツは決まっている。 はてさてどうしたものかとその瞬間は思ったものだが、無事仕組みとして載せられたので、備忘記しておく。 リアルタイムチャット機能 要件は以下。 クライアントはWebブラウザとネイティブアプリ (iOS, Android) 視聴者に軽量なテキストメッセージをbroadcastする メッセージの永続化必須 可用性/負荷分散も考慮する 例えば、動画を視聴しているとして、その動画の横に、自分含む視聴者のコメントが流れてくる、 ようなものを想像してもらえれば良い。 Socket.IO 「クライアント - サーバ間のリアルタイムなメッセージのやり取り」ということで、 WebSocket通信させる クライアントサイド/サー
socket.io を使っていると以下が問題になることがある。 これらを解決するのが socket.io-redis, socket.io-emitter, sticky-session というわけ。 【問題1】 clusterで複数プロセスを起動していると複数プロセス間で通信ができなくなる。 ユーザー1が接続を開始するとclusterがプロセス1に接続するように割り振る。 次にユーザー2が接続を開始するとclusterはプロセス2に接続するように割り振る。 この場合、ユーザー1とユーザー2が同じルームに所属していても、 接続を割り振られたプロセスが違うので通信できなくなる。 つまり、ユーザー1がルームに送信したメッセージをユーザー2が受信できない。 【問題2】 socket.ioはクライアントがトリガーになってメッセージを送信するので、 サーバからPUSHするタイプの送信はできない。 i
This is documentation for Socket.IO 3.x, which is no longer actively maintained. When deploying multiple Socket.IO servers, there are two things to take care of: enabling sticky session, if HTTP long-polling is enabled (which is the default): see belowusing the Redis adapter (or another compatible Adapter): see belowSticky load balancingIf you plan to distribute the load of connections among diff
20140826.md Express / Socket.IO をスケールアウトしてみよう Seiya Konno Works at Uniba Inc. (http://uniba.jp) https://twitter.com/nulltask https://github.com/nulltask https://fb.me/nulltask スケーラビリティとは システムの規模に依らず機能を適応できること リクエストに対するスケーラビリティ アプリケーションコードに対するスケーラビリティ Express https://github.com/strongloop/express 言わずと知れたウェブアプリケーションフレームワーク 右も左もわからなかった頃 => app.js の肥大化 メンテナビリティの低下 アプリの規模が大きくなってもメンテナビリティを確保したい Mounting
忘れないうちに「Socket.io」の使い方をメモ。 リアルタイム通信ができるので、ゲームやチャットアプリなどに使えそうですね。 今回は「Socket.io」を使用して簡易的なチャットアプリを実装してみました。 Expressインストール せっかくなので覚えたてのExpressを無駄に利用していくスタイル $ express chatapp -e からの $ npm install 以上。 不要なファイルやディレクトリを削除 EJSとかインストールしたけど別に使わなくていいので削除 routerも使わないので削除 ココらへんでExpressが全く必要がないことに気づくｗ chatapp/ ├ app.js ├ htdocs/ │ ├ css/ │ ├ index.html │ └ js/ └ package.json app.jsはhtdocsディレクトリ内のファイルをインクルードしてくる
追記 11/7/31 Socket.IO v0.7 解説を最初に途中までで出す。 11/8/1 だいたい全部新機能なので '(新機能)' って書くのやめた。 11/8/4 オプションの設定周りを追記 11/8/6 認証周りを追記 11/8/12 スタンドアローンのサンプルを追記 11/9/27 Socket.IO v0.8 対応について追記 11/9/27 タイトルを Socket.IO API 解説に変更 11/9/27 翻訳サイトリンク追加 公式マニュアル翻訳サイト そういえば公式サイトの翻訳をフォークしたリポジトリで、それなりの更新頻度でやってます。 リポジトリの wiki も地味に訳しててこっちは結構役に立ちます。本記事と合わせてどうぞ。 本家 http://socket.io/ 翻訳ページ http://jxck.github.com/socket.io wiki https:/
よくある負荷テストは弊社ではJMeterを使ってやることが多いです。 通常のHTTPリクエストならば問題無いと思います。しかしWebSocketを利用する場合は少し面倒な感じがしました。 ##Socket.ioの負荷テスト @nulltaskさんにiframeで確認すると良いというアドバイスを受けました。全然思いつきませんでした。 Webサイトへのアクセス負荷とSocket.ioのアクセスを分けるためにサーバーを分けています。 ##同時アクセスオンリーなテスト Amazon EC2 host: hogehoge-ec2.amazonaws.com port: 5000 console.log('接続数取得テスト'); var fs = require('fs'); var app = require('http').createServer(function(req, res) { res
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
