サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
『Google Docs』や『Figma』といったリアルタイムな共同編集ツールの恩恵を受けている人は数多くいるでしょう。『Visual Studio Live Share』のようなエンジニアに嬉しいツールも生まれ、今日ではオンライン上でも円滑なコミュニケーションが可能になっています。 これらのツールの基礎にあるのが「共同編集」のテクノロジーです。本記事ではこの技術に焦点を当て、その仕組みと主にフロントエンドでの実用例について紹介します。 記事の前半では、リアルタイムな共同編集に用いられる技術やアルゴリズムについて、発展の歴史とあわせて紹介します。解説用のコードにはJavaScriptおよびTypeScriptを使用しますが、フロントエンドエンジニアに限らず共同編集の仕組みについて気になる読者が知識を深めるきっかけとなるはずです。 さらに後半ではフロントエンドの開発者目線で、前半で紹介した技
昨今の衰えることのない技術トレンドに追従すべく、映像配信とかやりたいなーと思っていた2019年。 めっきり時間がなく何もできず、気付けば2020年になっていました。 今年も時間がないだろうなぁと思っていたところ、連日の在宅勤務のおかげで通勤時間がゼロになり、余暇が生まれたので色々やってみることにしました。 お題はHDMI入力で遊ぶ、です。 目次 ビデオ転送プロトコル 早速で ... Mzyy94 Multimedia 09 Apr, 2020 HDMI入力基板を用いてHDMI入力を扱いました。 Raspberry Pi公式のCamera Moduleとして認識してくれるので、何もせずにH.264で入力を扱えて楽でしたが、これはこれで問題を抱えていました。 再接続時に問題があることがこの時点ではわかっていたんですが、もっと使い込んでいくと入力解像度がおかしくなるなど、さらに問題があることがわ
緊急地震速報について¶ 緊急地震速報は、気象庁から発表される地震動の警報・予報のことで、震源に近い観測点でとらえた地震波（P波、初期微動）から震源要素等（震源・規模・発生時刻）を瞬時に推定し、強い揺れ（S波、主要動）の大きさおよび到達時刻を知らせるものです。本サービスは、緊急地震速報（予報）を用いて受信地点における震度や到達時間を予測してお知らせするものです。本データタイプ："earthquake"は、気象庁が定義する 「一般向け予報」 を提供するサービスです。 「特定向け予報」のサービスが必要なお客様はお問い合わせください。（離島などの1つの観測点の観測データに基づく予報を必要とする場合） 注意事項¶本サービスは、地震の発生を予知するものではありません。本サービスの出力は、気象庁が発表する緊急地震速報（予報）に含まれる予報資料（震源の位置・深さ、地震の規模、発生時刻）を用いて、気象
nginx(1.4.3)のproxyでWebとWebSocketのポート共有させてみました。以下、同時に試した項目です。WebSocketのproxy（ws://～） → OKWebSocketのproxy（wss://～） → OKWebのproxy（http://～） → OKWebのproxy（https://～） → OKマルチドメイン（ただし、SSLは１ドメインのみ） → OK 【動作確認ブラウザ】Chrome 30.0 → OKSafari (iOS6.1) → OKSafari 6.0.5 → OKMozilla Firefox 24.0 → OKIE 8.0 → NGIE 10.0 → OK その他の条件：Webサーバ（Apache）とWebSocketサーバの前にnginxを配置、同一ドメインに対する接続をWebサーバとWebSocketサーバへ振り分ける。WebSoc
先日、NginxのTCP Load BalancingがOSS版でも使えるらしいので試すで書いたとおり、Nginx 1.9よりTCP Load Balancing機能が使える見込みである。 今回は、更にTLS終端を可能にするngx_stream_ssl_moduleも合わせて使用し、WebSocket over TLSの負荷分散を試してみる。 ngx_stream_ssl_module ngx_stream_ssl_moduleでは、接続をTLSで受付け、その中身のメッセージをバックエンドに送信する。 TCP Load Balancingの時と同じようにHTTP/HTTPSに限った機能ではないことが特徴となる。 (ただし、ALPNが必要なプロトコルだと少々扱いが難しい) 使うには、前回同様最新リビジョンをビルドする必要がある http://hg.nginx.org/nginx/ より最新リ
経緯 WebSocketを使ったアプリケーションを作ったが、ポートが80しか使えないnginxでどっちも80に流したい ポイント / はまり所 WebSocketのプロキシにはUpgradeヘッダ(HTTP 1.1)への対応が必要 Upgradeヘッダへの対応はnginx v1.3.13以降 参考: WebSocket proxying 厳しい条件から先に書く デフォルトだと30秒通信がないと切断される（！）nginxでリバースプロキシしているときだけ一定時間で接続が切れるので何かと思えば、 普通のHTTPの通信と同様に30秒（だったはず）通信がなかった場合はタイムアウトってことで自動でコネクションを切ってくれていたみたい。 ping/pongを30s以内にやればいいんだろうけど、とりあえず5分に設定。 config server { listen *:80 default_serv
Elastic Load Balancerをつかってwebsocketを処理する方法AWSにはElastice Load Balancerというロードバランサがあります。これはとても安いこともあって多くのお客様のwebサービスで使っていただいています。 最近はwebsocketを使いたい!という声もありますが、いくつかの制限により、 ELBは最初のネゴシエーションにだけ使って、ネゴシエーション後のwebsocketにかかわらない方法がおすすめです。 そもそも問題は、 ELBの場合、HTTPモードだとそもそも同じポートのままではwebsocketに遷移できない。 ELBでTCPモードにした場合でも60秒でタイムアウトする。 の2点が原因です。そのため、2つの方法があります。 解1: ELBは最初のネゴシエーションにだけ使って、ネゴシエーション後のwebsocketにかかわらない方法 C ---------> ELB(HTTPモード) --> S ふつうにHTTPでアクセス。
WebSocket を利用するアプリケーションは Pub/Sub サーバを使ってスケールアウトさせるのが一般的です。 今回は Redis の Pub/Sub 機能を使って Phoenix の WebSocket をスケールアウトさせてみます。 Phoenix で WebSocket 通信をさせる方法はコチラをご参照ください。 事前知識: WebSocket アプリケーションのスケールアウトについて 通常の Web アプリケーションにおけるスケールアウトは、サーバ台数を増やしてロードバランサでリクエストを分散させる、というのが一般的ですが、WebSocket アプリケーションではこの手法が使えません。 なぜかというと、WebSocket アプリケーションはコネクションをサーバ内で管理するステートフルな作りになっているためです。冗長化させたサーバにリクエストを分散させてしまうと、他サーバで接続
Phoenix +AngularJS でMarkdown 同時編集ツールを作ってみます。 イメージとしては HackMD のようなものを目指します。 ことの始まり ElixirConf 2015 のタイムラインを眺めていたら、 I'm collaboratively editing a doc with 60 of my closest @ElixirConf friends. #phoenixframework pic.twitter.com/PlVexa3Anx — David Raffauf (@draffauf) 2015, 10月 1 Phoenix で同時編集ツールを作っている人がいて、「こういうのって自分でも作れるのかな」と漠然に思ったのがことの始まり。 完成イメージ 結論、こういうツールができました。GitHub で公開しています。 collabo_marker :
こんにちは。 今回は、当社で稼働させているリアルタイム通信環境について、ご紹介させて頂きます。 ご紹介する環境に対する要件は、以下となります。 ・ゲーム内の期間限定イベントで使用し、イベント開催中のみサーバを稼働 ・リアルタイム通信。プロトコルは、websocket を使用 ・同じチームに所属するユーザを同じサーバへ接続 ・とりあえずいっぱいスケールできるように(笑 最後の要件は冗談で、実際にはちゃんとした数値を頂いているのですが、このような環境構築を依頼されましたので、AWS 上で以下にあるような構成を考えてみました。 構成図 ※ 主要なサーバのみを抜粋 ELB 外部のクライアントから、websocket な接続を受け付けます。 http(s) モードでは、websocket の通信確立に必要なヘッダが消去されてしまうため、tcp モードを使用しています。 tcp モードを有効にすると、
LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフーTechBlog saegusa2017-04-16Yoshihiro was anetwork engineer atLINE, responsible for all levels ofLINE's infrastructure. Since being named Infra Platform Department manager, he is finding ways to applyLINE'stechnology and businessgoals to the platform. こんにちは。LINEでネットワークやデータセンターを担当している三枝です。2017年1月にJANOG39で登壇する機会を頂きましたので、今回
1リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
