100万回のWebSocket接続とGo | POSTD
こんにちは。私はSergey Kamardin（セルゲイ・カマルディン）です。Mail.Ru（ロシアの電子メールサービス会社）で開発者をしています。 この記事では、どのように私がGoを使って高負荷対応のWebSocketサーバを開発したかについて説明したいと思っています。 パフォーマンス最適化のアイデアやテクニックを通じて、WebSocketの知識はあるもののGoについてはほとんど知らないという方のお役に立てれば幸いです。 1. はじめに まずは開発に至った経緯について、どうして私たちがこのサーバを必要としたのかを説明しておきましょう。 Mail.Ruには多くのステートフルなシステムがあります。ユーザのeメール保存もその1つです。システム内、およびシステムイベントの状態変更を追跡する方法にはいくつかの種類がありますが、それらは主に状態変更に関するシステム通知、または周期的なシステムのポーリ
あなたにWebSocketは必要ないかも | POSTD
(訳注：2015/8/4、いただいた翻訳フィードバックを元に記事を修正いたしました。) 本題に入る前に強調しておきます。WebSocketは優れた通信プロトコルです。実際私はこの RFC6455 を、 Fanout のサービスで使っている( Zurl や Pushpin といったパーツで採用しています。Fanoutではまた、 Primus （異なるリアルタイムフレームワーク間での通信を可能とするラッパー）を利用し、 XMPP-FTWインターフェース を介したWebSocket通信をサポートしています。 しかしながら私はこれまで、多くの広く普及しているアプリケーションにかなりの時間を費やし、おかげでRESTやメッセージングパターンについては多少なりとも理解が深まってきた今、実はWebSocketを実装した典型的なWebアプリケーション（もしくはWebSocketライクな抽象化レイヤ）の大部分
Socket.IO 1.0の変更点・内部的な話
socket.io 1.0と0.9の比較や内部実装について。 node学園#13
Socket.IO 1.0の紹介 (翻訳) - from scratch
Socket.IO 1.0がリリースアウトされました。Socket.IO v1.0が出るといわれてから一年半以上経過しましたが、やっと出ました。Node.jsに関わる方であれば一度はお世話になっていると思います。今回はSocket.IO 1.0の紹介を作者であるGuillermo Rauchがしているので、それを日本語で翻訳して紹介します。 TL;DR 翻訳していたらすごく面白かったのですが、文字だらけですごく長くなってしまったので、最初と最後にまとめを載せました。興味があれば全部目を通してみてください。 モジュール分割が進み、新しくEngine.IOが作られています。これはSocket.IOのトランスポート層のプロトコルを調律する役割を担っているライブラリです。 Engine.IOが行っている処理の一つで、最初に接続できる可能性が高いXHRやJSONPで確立し、websocketにupg
『Node.js Cluster+Socket.IO+Redisによるリアルタイム通知システム』
Node.js Cluster+Socket.IO+Redisによるリアルタイム通知システム | サイバーエージェント 公式エンジニアブログ
Play2＋nginx/Akka/WebSocketで高速双方向通信
前回の記事「Play2（＋JavaScript）アプリを高速化、最適化する4つのテクニック」では、キャッシュの利用方法や非同期通信を行う手法、クライアントサイドでJavaScriptをうまく扱うテクニックについて紹介しました。 今回はPlay framework 2.x（以下、Play2）を既存のWebサーバーと連携させる方法、並列処理や双方向通信を行う方法を紹介します。 WebサーバーとPlay2の連携 Webサーバーと連携する必要性 連載第2回記事「Play 2.0のアーキテクチャとディレクトリ構成の基礎知識」で解説をしましたが、Play2では「Netty」というHTTPサーバーを内包しており、それを使用してリクエストを処理します。そのため、Play2の起動ポートを80番に設定すれば通常のWebサーバーと同じようにアクセス可能です。 単純なWebアプリケーションの場合はこれで問題はない
Ruby製WebSocketアプリを最速でHerokuにデプロイする５つのステップ
「テレビ放送が駄目になった」と言われて久しいですがその理由ははっきりしています。それは放送というものがリアルタイム・コンテンツを扱う媒体だからです。リアルタイム・コンテンツはユーザの自由を奪います。ある番組を見るためにユーザはその時間テレビの前に固定化されます。録画放送番組は字義的にはバッファード・コンテンツ1と言えますが、ユーザがそのコントロール権を持っていないつまりその視聴タイミングの制御を製作者側が持っているので、これはリアルタイム・コンテンツなのです。ユーザの唯一の武器はDVDレコーダによる制約の中のローカルバファリングのみです。 現在のWebは主としてバッファード・コンテンツを扱う媒体です。バッファード・コンテンツの世界ではユーザは好きな時間に好きなだけコンテンツを視聴できるという自由が与えられます。コンテンツの製作者側・提供者側にそのタイミングをコントロールする自由はありません
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Spring Bootでチャットツールを作りながらWebの仕組みを理解しよう！
HTML5の基礎と応用 ~Open Web Platform~ WebSocket / WebRTC / Web Audio API / WebGL 第三版
HTML5の基礎と応用 ~Open Web Platform~ WebSocket / WebRTC / Web Audio API / WebGL 第二版
WebブラウザでP2Pを実現する、WebRTCのAPIと周辺技術
HTML5と WebSocket / WebRTC / Web Audio API / WebGL 技術解説