GitHub - indutny/sticky-session: Sticky session balancer based on a `cluster` moduleYou signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
GitHub - websockets/wscat: WebSocket cat
Usage: wscat [options] (--listen <port> | --connect <url>) Options: -V, --version output the version number --auth <username:password> add basic HTTP authentication header (--connect only) --ca <ca> specify a Certificate Authority (--connect only) --cert <cert> specify a Client SSL Certificate (--connect only) --host <host> optional host --key <key> specify a Client SSL Certificate's key (--connec
大量接続に耐えるWebSocketアプリケーションサーバ構築のコツ - pixiv inside [archive]
WebSocketの扱うサービスでは、長時間のコネクション、再接続処理、プロキシ、ロードバランサなど、インフラの面で多くの問題を抱えがちです。弊社のサービス「pixiv」の9周年企画でも、この問題に直面しました。 実際にそこで構築したインフラの事例をもとに、本運用に使えるWebSocketサーバの構成について、pixivインフラ部の南川からご紹介します。 * 9周年企画 “黒歴史”をロケットで宇宙に飛ばす pixiv黒歴史 そもそも WebSocket とは？ WebSocketはTCP上で動く双方向通信のための通信規格です。 Webページの読み込みで行われているような、クライアントがサーバにデータを要求し、サーバはクライアントにレスポンスを返すというHTTPの通信ルールとは違います。サーバと長時間コネクションを確立し、Socketのようにデータのやり取りを行います。そして、コネクションを
![大量接続に耐えるWebSocketアプリケーションサーバ構築のコツ - pixiv inside [archive]](https://cdn-ak-scissors.b.st-hatena.com/image/square/95f08ea3414673bb0131022fbc9dc354bb7483ba/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fd%2Fdevpixiv%2F20161129%2F20161129204837.png)
サーバからクライアントに送信する技術 - WebSocketを中心に - Qiita
Webでのプッシュ技術 HTTPはクライアント（ブラウザ）からリクエストしてサーバからレスポンスが返る一問一答型のプロトコルなので、基本的にはサーバ側からブラウザに新着情報をリアルタイムで通知（プッシュ）できるようにはできていません。 しかしそれでもプッシュをしたいという場合にどうするかという話が出てきます。やり方には以下のようなものがあります。 ポーリング クライアントからサーバに定期的に新着を問い合わせるようにします。 最も原始的かつ確実なやり方。欠点は、最大でポーリング間隔の分だけ通知が遅延しうることです。 ロングポーリング（“COMET”） ポーリングなのですが、問い合わせを受けたサーバは新着情報がなければレスポンスを返すのをしばらく保留します。 そのあいだに新着情報が発生すれば即座にレスポンスを返しますし、一定時間経過したら何もなかったとレスポンスを返しましょう。 飛び交う通信内
Elixir + Phoenixでリアルタイムアプリケーションを作ってみるメモ - Qiita
最近話題の(?)Elixir + Phoenixを現在関わっているプロジェクトの検証・評価目的に使ってみます。 なお自分自身全くの初心者なので初心者向けの内容になる予定です。 Elixirとは Elixir公式サイトから引用します Elixir is a dynamic, functional language designed for building scalable and maintainable applications. Elixir leverages the Erlang VM, known for running low-latency, distributed and fault-tolerant systems, while also being successfully used in web development and the embedded softwar
Phoenix で Redis の Pub/Sub を使って WebSocket をスケールアウトさせる - Qiita
WebSocket を利用するアプリケーションは Pub/Sub サーバを使ってスケールアウトさせるのが一般的です。 今回は Redis の Pub/Sub 機能を使って Phoenix の WebSocket をスケールアウトさせてみます。 Phoenix で WebSocket 通信をさせる方法はコチラをご参照ください。 事前知識: WebSocket アプリケーションのスケールアウトについて 通常の Web アプリケーションにおけるスケールアウトは、サーバ台数を増やしてロードバランサでリクエストを分散させる、というのが一般的ですが、WebSocket アプリケーションではこの手法が使えません。 なぜかというと、WebSocket アプリケーションはコネクションをサーバ内で管理するステートフルな作りになっているためです。冗長化させたサーバにリクエストを分散させてしまうと、他サーバで接続
WebSocket and Web Application Framework - Qiita
WebSocket はネットワークの双方向通信の規格で、リアルタイム通信の用途で利用されています。 Web Application Framework の Phoenix は WebSocket を標準でサポートしています。 Rails も Action Cable で WebSocket の利用がサポートされるようになります。 そこで Express を合わせて３つの Framework で WebSocket のサンプルを作成しました。 ( bash コマンドの brew は Mac OS X で利用できます。他OSは適宜のコマンドを利用してください。 ) Node.js on Express Express は JavaScript が言語の Web Application Framework です。 Socket.IO という WebSocket のライブラリが有名です。 Setu
uu59のメモ | 人狼ゲームをSPA(Single Page Applicaiton)で作った
有給消化中で時間があったので今まで縁がなかった技術にどっぷり染まることにした。Ruby, JS（フロントエンド）,JS（サーバーサイド）、その他諸々をワンオペで作ったので個別に見てみると低品質かもしれない。ところどころデバッグコードや雑なコメントアウトやTODOが残ってそう。 コード： https://github.com/uu59/jinro-public （意味をなさないコミットや機微情報を含むコミットを乱発していて、それらを取り除いてきれいな歴史にするのが人間業では不可能な水準だったので全部なかったことにしてひとつの巨大なコミットにしたあと公開しています） 基本指針 なるべくコードベースやAPIなどがコンパクトなものを採用する。例えばRails、faye、webpackは候補から外れることになる。 いくらか使ったことのないものにも手を出すが無理はしない 2月中には見せれるレベルに達し
コラム - Ruby ＆ Rails | 第13回 WebSocketでサーバプッシュ その2 〜EM-WebSocket〜｜CTC教育サービス 研修/トレーニング
[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes 第13回 WebSocketでサーバプッシュ その2 〜EM-WebSocket〜 (松永紘) 2014年4月 3/14にRails4.0.4がリリースされました（*1）。このアップデートは多くの機能改修やバグフィックスが含まれています。その中にはRuby2.1.1の不具合（*2）に対するフィックスも含まれていますので、該当バージョンをお使いの方はアップデートすることをお勧めいたします。 さて、前回はWebSocketの概要について書いてまいりました。今回はその続きとして、実際にWebSocketを使ってみたいと思います。 WebSocketのライブラリとしてはJavaScriptで実装されたSocket.IO（*3）が有名ですが、本コラムは一
あなたにWebSocketは必要ないかも | POSTD
(訳注：2015/8/4、いただいた翻訳フィードバックを元に記事を修正いたしました。) 本題に入る前に強調しておきます。WebSocketは優れた通信プロトコルです。実際私はこの RFC6455 を、 Fanout のサービスで使っている( Zurl や Pushpin といったパーツで採用しています。Fanoutではまた、 Primus （異なるリアルタイムフレームワーク間での通信を可能とするラッパー）を利用し、 XMPP-FTWインターフェース を介したWebSocket通信をサポートしています。 しかしながら私はこれまで、多くの広く普及しているアプリケーションにかなりの時間を費やし、おかげでRESTやメッセージングパターンについては多少なりとも理解が深まってきた今、実はWebSocketを実装した典型的なWebアプリケーション（もしくはWebSocketライクな抽象化レイヤ）の大部分
Ruby製WebSocketアプリを最速でHerokuにデプロイする５つのステップ
「テレビ放送が駄目になった」と言われて久しいですがその理由ははっきりしています。それは放送というものがリアルタイム・コンテンツを扱う媒体だからです。リアルタイム・コンテンツはユーザの自由を奪います。ある番組を見るためにユーザはその時間テレビの前に固定化されます。録画放送番組は字義的にはバッファード・コンテンツ1と言えますが、ユーザがそのコントロール権を持っていないつまりその視聴タイミングの制御を製作者側が持っているので、これはリアルタイム・コンテンツなのです。ユーザの唯一の武器はDVDレコーダによる制約の中のローカルバファリングのみです。 現在のWebは主としてバッファード・コンテンツを扱う媒体です。バッファード・コンテンツの世界ではユーザは好きな時間に好きなだけコンテンツを視聴できるという自由が与えられます。コンテンツの製作者側・提供者側にそのタイミングをコントロールする自由はありません
「WebSocket, WebRTC, Socket API, … 最新Webプロトコルの傾向と対策」HTML5 Conference 2013 セッションレポート
「WebSocket, WebRTC, Socket API, … 最新Webプロトコルの傾向と対策」HTML5 Conference 2013 セッションレポート 吉田 啓二 2013年11月30日（土）に開催された「HTML5 Conference 2013」の、エヌ・ティ・ティ・コミュニケーションズ株式会社・小松健作さんによるセッション「WebSocket, WebRTC, Socket API,…最新Webプロトコルの傾向と対策」の内容をご紹介します。 最新のWebプロトコルが続々と誕生 1990年から10年間ほどは、HTTPというたった一つのプロトコルが、Web通信用のプロトコルとして使われていました。その後、HTML5という言葉が出てきてから、WebSocketやSPDY、HTTP/2.0、WebRTC、Raw Socket API、SCTP over UDP、QUICといった
WebSockets on Heroku | Heroku Dev Center
The WebSocket protocol is a core technology of modern, real-time web applications. It provides a bidirectional channel for delivering data between clients and servers. It gives you the flexibility of a TCP connection with the additional security model and meta data built into the HTTP protocol. For more details on the WebSocket protocol refer to RFC 6455, which is the version supported on Heroku.
I am mitsuruog | websocketを使う際の意外な落とし穴
本ブログは東京 Node 学園祭 2012 アドベントカレンダーの 6 日目の記事です。 今回はnodejitsuを使って sockect.io を使ったアプリをホスティングしたところ、websocket（以下、ws）まわりで思わぬハマりポイントがあったというお話しをします。 （同じようなトラブルで悩む方に少しでもヒントをあげられたらと考えています。） このエントリでお伝えしたいこと。 ws 通信は 443 ポート（wss）で行った方が良い。 ws のみがブロックされた場合に socket.io が怪しい挙動をする…（Help me!） nodejitsu なかなか好いよ。 ws 通信は 443 ポート（wss）で行った方が良い。 既に周知の事実かもしれませんが、通常の HTTP（80 ポート）を使って ws 通信を行った場合、 サーバから送信された ws の通信データが、クライアントのブ
Server-Sent Eventsの利用(1/5):JavaScriptによるHTML5プログラミング入門 - libro
サーバーとクライアントの間で通信を行い、サーバーから必要に応じて値を受け取る――HTML5が登場するまで、こうしたことが可能な技術は「Ajax」があるのみでした。しかしAjaxは、クライアントからサーバーに接続し、結果を受け取って終了……といったものであり、「接続を維持して、必要があればサーバーからクライアントへ情報を送ってくれる（いわゆる、PUSH送信）」などは行えません。 サーバーと常時接続を維持するものとして、HTML5では新たに「Web Socket」という機能が追加されました。これを使えばサーバーとの通信も完璧です。が、このWeb Socketは、HTTPではなく独自のプロトコルを利用して通信を行うため、Webサーバーとは別に専用のサーバーを用意しなければいけません。現時点ではWeb Socketサーバーに対応するレンタルサーバーやクラウドサービスもほとんどなく、利用は狭き門とい
Server-Sent-Eventsとは
Server-Sent Eventsとは、サーバー側で何らかの出来事が起きたことを、リアルタイムでクライアント側に知らせることを可能にする技術です。 一般的なウェブサーバーとの通信では、クライアントは問い合わせ（リクエスト）を送ってはじめて、サーバー側の状態を知ることができます。そのため、サーバー側の状態の変化をリアルタイムで知るには、通常は一定の間隔でリクエストを何度も送る必要があります。 しかし、この方法では、頻繁な再接続による負荷は避けられません。加えて、再接続のたびにユーザーの操作がクリアされないようにする配慮も必要になってきます。 Server-Sent Eventsの仕組み Server-Sent Eventsでは、イベントをリアルタイムで伝達するための専用のテキストデータによる通信（イベントストリーム）を、ブラウザのバックグラウンドでサーバーとクライアントの間に開きます。 こ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - joewalnes/websocketd: Turn any program that uses STDIN/STDOUT into a WebSocket server. Like inetd, but for WebSockets.
Web sockets make ajax/CORS obsolete?
http://atnd.org/events/21979
Backbone.js on WebSockets - Comoyo Engineering