- バージョン
0.0.2
- URL
良く会社説明するときに話をしている内容をざっくりとまとめておく
- 比較的大きめのシステムを中心に設計から開発まで技術支援を行っている
- 大規模向けステートフル Proxy が興味の中心
- MQTT 関連
- MQTT as a Service sango
- 2014-08-28 リリース
- https://sango.shiguredo.jp/
- 時雨堂 MQTT as a Service Sango 開発ログ
- MQTT Broker Akane
- 2014-12-08 リリース
- http://akane.shiguredo.jp/
- 時雨堂 MQTT ブローカー開発ログ
- MQTT Gateway Fuji
- 2015-04-22 リリース
- http://fuji.shiguredo.jp/
- 時雨堂 MQTT ゲートウェイ Fuji 開発ログ
- MQTT as a Service sango
- WebRTC 関連 - NTT コミュニケーション様向け WebRTC シグナリングサーバー
- WebRTC SFU (開発中)
- WebRTC 向け TURN/STUN サーバ
- WebRTC Conference Japan
- http://webrtcconference.jp/
- WebRTCの裏側 シグナリングと TURN/STUN のプロトコル解説
- WebRTCエキスパート座談会 WebRTCが世界に与えるインパクトを探ろう
- WebRTC スタックコトハジメ
- 元々は携帯キャリアや大手 ISP 向けの RADIUS 認証サーバの設計/開発/マネージメントを担当
- Erlang/OTP という開発言語をメインとして落ちにくいシステムを開発
- 最近は Erlang/OTP + Lua という構成で、ネットワークは Erlang/OTP でロジックを Lua で開発する仕組みも取り入れている
- 自動負荷試験や自動障害試験に興味あり
- 接続環境が悪い環境向けの PubSub プロトコル
- MQ と間違われるが、MQ 機能は持っていない
- ヘッダーは少ないがペイロードは変わらないので、データが大きいと HTTP と特に変わらない
- サーバ実装が大変
- クライアントはシンプル
- セッションや切断時の通知、QoS など、便利な機能がある
- サーバが面倒な部分を全て吸収するためクライアント側の開発コストが低い
- MQTT プロトコル自体が枯れている
- あくまで土管なので、機能をアプリ側に寄せられる
- サーバからの配信が可能
- 動的なパーミッションを管理する必要がある
- アプリ開発に強い会社が必要
- 配信だけだとあまりメリットがない
- fluentd や fluent-bit など安定している配信ツールが存在する
- クライアントがまだまだ成熟しきっていない
- 企業が付いて応援しているわけではない
センサーネット向けのプロトコル
- MQTT は TCP だが MQTT-SN は UDP または no-IP 前提
- MQTT-SN over BLE や MQTT-SN over XBee など
興味あれば