GitHub - olahol/melody: :notes: Minimalist websocket framework for GoYou 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
100万回のWebSocket接続とGo | POSTD
こんにちは。私はSergey Kamardin（セルゲイ・カマルディン）です。Mail.Ru（ロシアの電子メールサービス会社）で開発者をしています。 この記事では、どのように私がGoを使って高負荷対応のWebSocketサーバを開発したかについて説明したいと思っています。 パフォーマンス最適化のアイデアやテクニックを通じて、WebSocketの知識はあるもののGoについてはほとんど知らないという方のお役に立てれば幸いです。 1. はじめに まずは開発に至った経緯について、どうして私たちがこのサーバを必要としたのかを説明しておきましょう。 Mail.Ruには多くのステートフルなシステムがあります。ユーザのeメール保存もその1つです。システム内、およびシステムイベントの状態変更を追跡する方法にはいくつかの種類がありますが、それらは主に状態変更に関するシステム通知、または周期的なシステムのポーリ
WebSocket大合戦：Clojure、C++、Elixir、Go、NodeJS、Ruby | POSTD
Webアプリにリアルタイムの双方向通信が必要な場合、WebSocketを選ぶのは自然なことだと思います。では、どのツールでWebSocketサーバを構築すべきでしょうか。パフォーマンスは重要ですが、開発のプロセスも見過ごしてはなりません。パフォーマンスを基準にするだけでなく、開発のしやすさも考慮に入れるべきでしょう。今回の大合戦では、Clojure、C++、Elixir、Go、NodeJS、Rubyのそれぞれの言語によって慣用的な手法で実装されたシンプルなWebSocketサーバを比較したいと思います。 テスト内容 サーバに実装するのは、 echo と broadcast の2つのメッセージのみを扱う非常に単純なプロトコルです。echoは送信クライアントに返され、ブロードキャストは全ての接続クライアントに送信されます。そしてブロードキャストが完了すると、結果メッセージが送信者に返されます。
大量接続に耐える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)
Pusher | HTML5 WebSocket Powered Realtime Messaging Service
Powering realtime experiences for mobile and webBi-directional hosted APIs that are flexible, scalable and easy to use. We create and maintain complex messaging infrastructure so you can build the realtime features your users need, fast. Bi-directional hosted APIs that are flexible, scalable and easy to use. Get started today and find out what you can build with Pusher
Phoenix でログファイルをリアルタイムに tail してみる - Qiita
defmodule PhoenixTail.TailChannel do use Phoenix.Channel def join("tails:sample", auth_msg, socket) do {:ok, socket} end def join("tails:" <> _private_room_id, _auth_msg, socket) do {:error, %{reason: "unauthorized"}} end end ログファイルを監視するプロセスを作る 次に、tail の対象とするログファイルを監視する部分を実装します。 処理の流れとしては、 定期的に対象のファイルをチェック 変更が入っていれば、前回取得行以降の行を取得 取得した内容を WebSocket に broadcast という感じで、サーバへのリクエストなどとは一切関係ないものとなります。 つまり
Cross-Site WebSocket Hijacking (CSWSH)
Hijacking WebSocket ConnectionsThe relatively new HTML5 WebSocket technique to enable full-duplex communication channels between browsers and servers is retrieving more and more attention from developers as well as security analysts. Using WebSockets, developers can exchange text and binary messages pushed from the server to the browser as well as vice versa. During some experiments and pentests w
Pairy : Ratchet PHP & ZeroMQ でリアルタイム通信 - Tech Blog
CTOの椎名アマドです。 昨日弊社Pairyは１億円調達の発表を行ないました！ 色々な方から嬉しいメッセージなどが届いて嬉しい限りです。 ちなみにエンジニア採用を本格的に行なってるので、興味ある人は http://timers-inc.com を見てみてください！ さて、今回はリアルタイム通信に関してです。 前々から我々は Pairy にwebsocket使ったリアルタイム通信を導入したいねと言っていて、最近やっと導入に成功しました。 Ratchet と ZeroMQ という２つのライブラリの組み合わせによって、比較的簡単に実装できてます。 設計の概要 設計はざっくりと： 1. ネイティブアプリAが投稿などのアクションを行ない、webサーバーにリクエスト送信 2. webサーバーがDBサーバーに書き込み 3. webサーバーがsocketサーバーにメッセージをZeroMQ経由で送信 4.
チャットなどリアルタイム更新が必要なスマフォアプリの構成について考えてみた - Qiita
今開発しているPlayer!で、チャット系のリアルタイム更新処理が必要となったので、色々調べています。 ※「スマフォアプリ」として共通事項が多いのでそう表記しましたが、基本的にスマフォアプリはiOSアプリとして書いてます。Android・Windows Phoneなどは差異があったり読み替える必要があると思っています。 結論 後半で詳しく書きますが、今のところ以下の結論に至りました。 PUSH通知に全て依存する構成でもそれなりに動く PUSH通知 + 双方向通信処理(WebSocketなど)の併用がベスト 双方向通信処理はPusher・Firebaseなどのサービスに頼る or ws・Socket.IO・SignalR + 対応クライアントライブラリなどで自前実装 Pusherなど有名サービスのクローンOSS導入も良さそうです stevegraham/slanger edgurgel/po
Node.jsによるPusherクローン「Keima」をリリースしました #codefirst - みずぴー日記
http://keima.herokuapp.com/ 「えーpolling!? pollingが許されるのは小学生までだよねー、キャハハハ」というわけでpush通知にWebSocketをお使いのみなさま、こんにちは。 しかし、毎回、WebSocketを扱う機能を実装するのは、いくつかの理由で面倒ですよね! WebSocketは様々なバージョンがあるので、すべてに対応するのは面倒。 同様の理由で、個別のアプリで作り込んでしまうと、WebSocketのバージョンアップに追従するのが面倒。 WebSocketは大抵別サーバになっているので、設定が面倒。 Heroku等のPaaSではWebSocketを使えないことが多い。 (2015/1/23追記: HerokuはWebSocketをサポートするようになりました) そこで、WebSocketによるpush通知に特化したWebサービス Keima
クロスドキュメントメッセージングやWebSocketを使ってみる
＊）オリジンとは、プロトコル、ドメイン、ポート番号の組み合わせの事です。 サンプル一式は、会員限定特典としてダウンロードできます。記事末尾をご確認ください。 従来のHTTPによる通信では以下のような問題や制約があります。 メッセージの送信時に毎回接続を確立して送信後に切断する必要があり、オーバーヘッドが大きい。 接続を開始する権利はクライアント側にしかなく、サーバー側は要求に対する応答の形のみでしかデータ送信出来ない。 各メッセージ送信において状態を維持する事ができない。 クロスドメイン（クロスオリジン）での通信はできない これらの制限が、効率的なリアルタイム性のあるリモートアプリケーションの作成や、他サイトの提供するサービスの組み合わせでWebサイトを構築する場合に、他の技術も使用しなければならず、実装が複雑になってしまう原因となっていました。 しかし、HTML5の上記の新機能により、サ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TechBuzz第5回cocos2d-x勉強会 BrainWars発表資料
SockJS
Rocket.Chat: Communications Platform You Can Fully Trust