Discord の採用している技術
Discord はゲーマー向けのボイスチャットサービス。テキストチャットもできるし最近ではビデオチャットや画面共有もできるようになった。 UI はかなり Slack に似ている、モダンなデザインということなんだろう。 WebRTC 技術を利用しているということで、とても気にはなっていたが使うタイミングがなかったことからあまり追いかけていなかったが、先日ビデオチャットと画面共有が追加されたということで色々調べてみることにした。 ElectronWindows/Mac/Linux 向けのデスクトップクライアントには Electron を採用している。かなり早い段階から採用しているイメージ。Electron は Chromium ベースなので WebRTC が利用できる。WebSocket もバリバリ使ってる模様。 Electron を使うことでブラウザとほぼ変わらぬ動き、UI を再現している。
HTTP API の設計方向
見てみると、たしかに Get 系の API だとしても POST を利用しているし、API の URL 設計に get_shared_link_file のようによく言われる REST っぽい設計は使っていなかった。 この方針は同意だ。自分は結構前に REST っぽい API を捨てることにした。だからといって REST API がダメだとかは思っていない。 一般ユーザが使う場合の API は REST API であるほうが慣れ親しんでいる場合が多いからだ。 AWS で利用されている HTTP API 仕様AWS の DynamoDB の Erlang/OTP ドライバーを書いているときに気づいたのだが、AWS の一部のサービスはかなり独特な API の仕様になっている。
Erlang で仕事する一つの方法
これは 2007 年頃の話です Erlang/OTP って何？という時期に Erlang/OTP で製品を作って利益を上げた日本人はあまりいないとおもう。 せっかくなので振り返りついでに、自分の昔話を書くことにする。 Erlang/OTP の導入まで仕事でネットワークサーバを触ることになったのだが、当時の製品はシングルスレッドだった。当時はもうマルチコアだという話がでており、ではマルチコアを有効に使えるネットワークサーバを書くにはどうしたらいいのだろうか？というところから入った。 Erlang/OTP をやる前は Python で Django というところに興味があったくらい普通のウェブアプリスキーだった。 そのため何を血迷ったか Python でとりあえずネットワークサーバーを書いてみることにした。 stackless python 使ったり Twisted 使ったり multipro
夕凪堂という会社を作った
会社を作った。夕凪堂というテストに関するいろいろを扱う会社。 詳細は Gist にだらだらと、アイデアレベルでまとめてるので興味があれば。 もともとテストに対しては、いろいろ考えることがあるのだが、ネットワークサーバを開発していると、凄くテストが重要になる。 たとえば秒間 100 リクエストを処理出来る製品としてアピールして売っていく場合は秒間 100 リクエストの負荷がかけられるテストツールが必要になる。 さらに、開発を続けている間に製品はでぶっていく。ただしそのアピールは変更できない。となると「継続的な負荷テスト」が必要になる。 これ、難しい。いろいろ環境も状況も変わっていく中で定常的に負荷テストを行えるってコストがとても高い。夕凪堂はそこのコストを減らすためのツールを売る会社だ。 ターゲットは継続的な負荷テストを行いたい会社という狭い狭い範囲を狙っている。 もともと時雨堂でやりたかっ
Rust はじめました
Rust は mozilla が開発している言語で、コンパイル型の言語だ。 なぜ Rust なのか理由があるのでそれを上げていこう。 パターンマッチがあるcargo によるパッケージ管理便利1 バイナリ強力な型推論Erlang/OTP と比べて圧倒的に処理性能が早いまずパターンマッチ。Erlang/OTP をメインで使っているものとしては本当にこれがないとツライ。 デフォルトでパッケージ管理システムが入っているのはとても良い。cargo はシンプルでとても良く出来ている。設定ファイルもわかりやすい。 コンパイルして生成されるバイナリ、これ一つで事足りるのはとても良い。 型推論や速度はまぁその通り。早いの大事です。 Rust と比較されるが、実際は全然違うと思う Golang だが、とても素晴らしい。特にクロスコンパイルが良い。さらに性能、ライブラリの充実、シンプルで無駄を省いている言語だと
QUIC の RFC ドラフトがリリースされた
QUIC ( Quick UDP Internet Connections、「クイック」と発音) とは Googleが開発している実験的な トランスポートレイヤー ネットワークプロトコルで2013年より実装している。 User… 詳細については Wikipedia を読んで貰ったり大津さんの記事を読んでください。 Googleが仕掛ける新プロトコルQUICとは何か http://d.hatena.ne.jp/jovi0608/20130227/1361975933 とても詳しくまとまっているので、読めばわかるんですがもっと実装者側の視点に立って考えてみることにします。 最近は通信経路を暗号化するのが前提になってきています。ほとんどの場合で TLS over TCP を使っているのではないでしょうか。ただこれって効率はそんなにイイとは言えないんですよね。 TCP を貼った後に TLS で再度
Multistream を勝手にまとめる
なんとなーくわかったら、次はこちらを読みましょう。 Negotiating Media Multiplexing Using the SDP https://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-20 まとめます ブラウザの API 側では簡単に既存のコネクションに対してストリームを動的に追加したり削除したりすることが出来るようになったつまりビデオ＋音声に加えスクリーンシェアなどを一つの接続で扱えるようになったWebRTC SFU 視点で見てみると、とても良い仕組みであることがわかります。 今までは上り 1 下り N (参加人数から自分を引いた値) だったのが 1 本の DTLS を SFU に貼るだけで良くなりました。ただし今までのようなシグナリングの仕組みは使えなくなり、DTLS 内部でのセッションを
WebRTC サーバを開発する理由
ブラウザ同士がやりとりする WebRTC 、当たり前だが WebRTC をサーバ側に用意することでブラウザとサーバでのやりとりを実現する事ができる。 理由はたった一つでサーバ側で配信データをコントロールすることが出来るようになるからだ。 通常の WebRTC を使って一人が複数人に配信する場合はこうなる 大きく違うのはサーバがブラウザを管理したり、データの流れを管理できるようになることだ。これはニコニコ動画の生放送をイメージして貰えば良いと思う。 もちろんサーバを経由することでサーバ側での録画も可能になる。もともとクライアント側で録画はできたが、P2P で動作されるとサーバ側での録画は難しくなるからだ。 これらの仕組みをプラットフォームとして提供しているのが tokbox だ。
Electron が良さそう
注意: 私は Electron を触ってみたわけではありません。単に、色々なところに書いてある資料を読んだだけで、これを書いてます。 Electron は元々 atom-shell で Atom を作るために作られたとか何とか思っていたが、Qiita の Kobito for Windows が Electron で作られていてとてもよさそうだと感じたので、ちょっと調べてみた。 良さそうだと思ったところ Chrominium ベースなので HTML/JS/CSS で開発単独ネイティブアプリ(Mac/Windows/Linux)WebSocket や WebRTC が使えるブラウザで表示してはいるけど、固定環境になるので互換とかを考えなくてよい。色々あるのだけれど、思いつくだけで結構メリットがある。デメリットはおそらく実際に作っていくと色々あるのだろう。そこはまぁ、手を動かすしかなさそう。自
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
