「NAT(ナット)※1」はオンラインゲームを支える重要な技術のひとつです。 「NAT越え※2」に失敗するとマルチプレイができなくなりますし、「NATタイプ※3」の違いはマルチプレイのしやすさに影響します。 ところが、NAT は仕組みが難しく、初心者向けの記事も少ないため、イカスミカフェには NAT についての質問がよく寄せられます。 そこで今回は、Nintendo Switch(ニンテンドースイッチ)を例にして、世界一わかりやすく NAT を解説してみたいと思います。
2022年9月9日、「スプラトゥーン3」が発売されました。とても楽しみにしていたのですぐに買いました。発売から1月半ほどたってこの文章を書いていますが、いろいろなステージで様々なブキを使ってインクを塗り合い楽しくプレーしています。ちなみに今のウデマエはS+30になったところです。 この特集は、人気のスプラトゥーン3を通して、最新の通信技術の基本を学んでしまおうというものです。前半の今回はスプラトゥーン3を含むオンラインゲームの通信技術を解説します。後半となる次回は、実際にスプラトゥーン3のパケットをキャプチャーして、それらの通信技術が実際にどのように使われるのかを見ていきます。 なお記載内容については、筆者や編集部独自の考察や推測によるものであり、任天堂の公式見解ではないことを明記しておきます。 オンラインゲームを実現する通信技術、UDPとは 一般的なコンピューターが通信を行う主な方法にT
AWS“から”オンプレミス“に”松浦庸介氏(以下、松浦):SRE部の松浦から「WebRTCの配信システムをAWSからオンプレミスに切り替えている話」ということで発表したいと思います。 まず、簡単に自己紹介をしたいと思います。2020年の5月に入社して、それ以来WebRTCのリアルタイム配信システムの開発や運用を担当している、松浦と言います。本日はよろしくお願いします。 まずこのタイトル、みなさん「AWS“から”オンプレミス“に”」というところ、気になってる方がいるんじゃないかと思います。 これ「AWS“に”オンプレミス“から”じゃないか」と思っている方もいるかもしれませんが、実は本当に「AWS“から”オンプレミス“に”」移行している話になります。その経緯などを含め、説明していきたいと思います。 WebRTC配信システムの特徴まず、WebRTC配信システムの特徴から説明したいと思います。We
はじめに はじめまして、セキュリティエンジニアのSatoki (@satoki00) です。今回はブラウザの開発者ツールのネットワークタブから隠れて、Webサイト内の情報を送信する手法をまとめます。所謂Exfiltrationというやつです。中にはCSPの制限をBypassするために用いられるテクニックもあります。CTFなどで安全に使ってください。 前提 発端はWeb上でテキストの文字数をカウントできるサイトが閉鎖する際の話です。カウント対象のテキストデータがサイト運営 (やサイトを改竄した攻撃者) に盗み取られていないかという議論が巻き起こっていました。「盗み取られていない」側の主張は、ブラウザの開発者ツールのネットワークタブにリクエストを送信した形跡がないというものでした。ここで ブラウザの開発者ツールのネットワークタブに表示がなければ外部へデータを送信していないのか? といった疑問が
learning-webrtc_2023-05.md 時雨堂 WebRTC 入門 (講師資料) v2023-05 これは時雨堂が開催しているオンラインイベントである WebRTC 入門の 講師用 の資料であり、 参加者用の資料ではありません。 時雨堂 WebRTC 入門 オンラインイベント 概要 ChatGPT がある今、学ぼうと思えば好きなだけ学べる時代がきています。 ただ「正しい情報」をなんとなく知っている事はとても重要だと考えています。 進め方 今回の WebRTC 入門はまず最後まで大まかに話をしていきます。 その後、残り時間を利用して、細かく話をしていきます。 資料表示用の画面と iPad を画面共有してホワイトボード的な使い方をしていきます。 お願い 是非 Discord にメモを残していってください。 後から振り返るとき、参加者の皆に有用だと思います。 ライセンス Creat
はじめに 家庭用ゲーム機などのネットワーク設定で「NATタイプ」というのを見たことがある人は多いと思います。 これはオンラインマルチプレイなど通信を行うゲームをする際、ゲーム機器同士で通信可能かどうかを見極める目安として使われます。 本記事では、このNATタイプをどのように判定するのか、 RFC 5780 ベースで簡単に説明します。 この記事はDeNA Advent Calendar 2021の8日目の記事です。 なぜNATタイプの判定を行うのか 一般的なクライアント/サーバモデルの通信であれば、そもそもNATタイプが何であるか気にすることはないと思います。 では、家庭用ゲーム機などがなぜNATタイプを判定するのかというと、「P2Pが成立するかどうか」を見極めるためです。 P2Pで通信を行う際は、NAT(NAPT)が存在する場合、いわゆる「NAT越え」が必要になります。 NATがあると、イ
大変反省したので、何をやっていて、どんな会社なのか書いていきます。知ってもらうためにも定期的に更新していければ思っています。 まとめ零細企業リアルタイムな音声と映像を扱うミドルウェア製品を作って売ってるミドルウェアのクラウド版を作って売っているサブスクリプションモデルの積み上げ型OSS 重視何をやってるのか時雨堂はミドルウェアソフトウェアをパッケージとして開発、販売しています。最近は「リアルタイムな音声と映像、データの配信」に特化したミドルウェアがメインです。 現在の主力製品は WebRTC SFU Sora (以降 Sora)という本来は P2P で利用する WebRTC を、クライアント・サーバー方式で利用するソフトウェアを1 から開発して、販売しています。売上のほとんどはこの製品関連になります。 製品はサブスクリプションを採用しており、 3 ヶ月、6 ヶ月、 12 ヶ月単位で Sor
QUICはこの10年で世界的な規模で使用されるようになった新しいプロトコルのひとつであり、ネットワークにもこれまでになかったインパクトをもたらしています。本セッションではQUICがネットワークに与える影響をご紹介しますが、これがQUICの導入を検討する開発者やネットワーク運用者のお役に立てれば幸いです。 本記事は、TechFeed Experts Night#13 〜 HTTP3/QUIC…Webプロトコル最前線のセッション書き起こし記事になります。 イベントページのタイムテーブルから、その他のセッションに関する記事もお読み頂けますので、一度アクセスしてみてください。 本セッションの登壇者 セッション動画 @yuyarinと申します。前職では@kensaku_komatsuさんと同じ会社でクラウドを作っていました。現職はモバイルキャリアでエッジコンピューティングの基盤を作っているので、ぜひ
始めようと思ったきっかけ Twitchのクローンサイトを作りたいとずっと考えていて、おおえのたかゆき(おえちゃん)さんが配信できるサイトを探していると知って作成に取り掛かりました。なのでおえちゃんの元々配信していたサイトであるOPENRECにちなんで、サイト名はOpen放送室にしました。 使った技術 サーバープロバイダー Linode フロントエンド Next.js NextUI バックエンド Express.js Socket.io Docker Nginx RTMP HLS Redis Cloudflare Ubuntu 24.04 LTS 環境 NginxでRTMPとHLS配信 NginxでAPIとクライアントへのリバースプロキシ 全ての通信はCloudflare経由 ①初期段階の構成 第一回目のテスト放送での出来事です。 結果から言うと600人ぐらいで落ちました。 サーバー Ubu
GW なんも予定がなくてブログ書くかソシャゲやるか昼から酒飲むしかやることがないです。だから予定があったら使っていたであろうお金でソシャゲに課金したらめちゃくちゃ強くなりました。やったー。友達にはドン引きされましたが、GW に予定がある人よりかは節約できていると思います。そんなソシャゲもやることなくなって暇なので酒飲みながらブログを書きます。今日は WebRTC です。 免責 筆者は RFC を読んでいません。これは「そもそも WebRTC それ自体 の RFC なんてものは存在しないもんね〜」という意味でなく、ICE や SDP の RFC すら読んでいないという意味です。そのため WebRTC そのものの解説として読むと良くない表現が含まれるかもしれません。ただし自分が WebRTC でカメラ映像を送る実装を動作させ、そのコードの解説という点では間違ったことは書いていないはずです。動作
WebSockets vs Server-Sent-Events vs Long-Polling vs WebRTC vs WebTransport For modern real-time web applications, the ability to send events from the server to the client is indispensable. This necessity has led to the development of several methods over the years, each with its own set of advantages and drawbacks. Initially, long-polling was the only option available. It was then succeeded by Web
2013 年 3 月 8 日に時雨堂を創業し、2024 年 3 月 8 日で時雨堂創業 11 年、そして 12 年目にはいりました。あっという間です。 起業のきっかけは、ある経営者に「貴方がどんなに一生懸命に製品を作ってもそれは会社のものでしかないので、自分の会社を持って自分の製品を作って、売った方がいい」といわれた事なんですが、それから 11 年立ちました。 起業したときから状況も大きく変わりました。自社製品の売り上げだけで会社が回っています。今後の時雨堂について雑に書いて行きます。 少人数でスケールする製品を作り続ける時雨堂はパッケージソフトウェアのサブスクリプションで稼いでいる会社です。営業もいないため、買いたいといってくれる企業に売るだけです。 社員が社内にあるライセンス発行サーバーに Tailscale でリモートで繋いでライセンス (JSON ファイル) を発行し、ライセンスフ
この前ポジショントークしたらそれなりに反響があったので書いてみる。 これまでの人生を振り返ると毎年ラジオや電話や配信サービスを作っている気がするし、なんかそういう仕事が回ってくることが多い気がする。 最近自分なりに答えが出たかなと思ったことがあるので言語化してみようと思う。 OGP は Flux ぽい画像だ。 注意・免責事項 ここにあるソースコードは不完全です。これは私が元々手元で実験していたボイラープレートであるとはいえ、いろんな仕事で培ったノウハウ的なものも含まれているので、念には念を入れて意図的に要件が透けそうな箇所は削除しています。 その結果元々のボイラープレートと乖離してしまい、動作しないコードになっています。ただ概念を伝えるには十分なコードになっているはずなので、脳内補完してください。質問は Twitter のメンション、もしくは Issue でのみ受け付けます。 (完全版を書
概要 この記事では、サーバーコストを一切かけずにブラウザだけで動作するリアルタイム対戦ゲームを開発した際の、技術的な裏側をご紹介します。WebRTC (PeerJS) によるP2P通信を主軸に、マッチングを仲介するシグナリングサーバーをRender、フロントエンドをGitHub Pagesにデプロイすることで、完全無料で遊べるブラウザオセロゲームを実現しました。 ゲームをプレイする: https://kinn00kinn.github.io/osero_p2p_front.github.io/ フロントエンド (GitHub): https://github.com/kinn00kinn/osero_p2p_front.github.io マッチングサーバー (GitHub): https://github.com/kinn00kinn/osero_p2p_render はじめに 皆さんは
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? これは CAMPFIRE Advent Calendar 2024 の 13日目の記事です。 他の方がCAMPFIREに関連したことを書く中、去年に引き続き、あまりCAMPFIREとは関係なく記事を書きます(去年は量子コンピューティングでした)。去年よりはWeb技術なのでCAMPFIRE寄りの内容です。 さて、みなさんはWebのリアルタイム通信、双方向通信といえば、何を思い浮かべるでしょうか? おそらく、WebSocketが一番多いのではないでしょうか。ちなみに私もそうです。 それ以外にもW3Cで標準化済みやドラフトの技術として、Ser
X(旧Twitter) で突然フォロワーが恐ろしく増えた。それも中国圏の方々からのフォローでなんだなんだとドキドキしていた。正直スパムか?と思った。 ただ、フォローしてくる人たちのプロフィールには、 GitHub アカウントだったり、ソフトウェアエンジニアとか、プログラマーとか C++ とか Python とかの文字がやけに多かったので、ブロックしたりはせず、ドキドキしたままだった。 そして理由はこれ。有名なオープンソースプログラマーの方が、時雨堂を紹介してくれていた。 私は時雨堂という素晴らしい日本の会社を発見しました。 日本のインターネット企業とは違う。 彼らは新しいテクノロジー (zig) を追いかけているだけでなく、オープンソースを特に受け入れており、主に使用しているテクノロジーの開発者のほとんどをスポンサーしており、公式 Web サイトにもリストされています。 海外の方に OSS
Overview 画像/音声処理をリアルタイムで行う、Webブラウザから利用できるアプリをStreamlitで作る方法を解説します。 StreamlitのおかげでPythonだけでwebアプリが作れます。さらに、一番簡単な例なら10行程度のPythonコードで、webカメラを入力にしてブラウザから利用できるリアルタイム画像処理アプリケーションになります。 Webベースなのでクラウドにデプロイでき、ユーザに簡単に共有して使ってもらえ、UIもイマドキで綺麗です。 人物・物体検知、スタイル変換、画像フィルタ、文字起こし、ビデオチャット、その他様々な画像・音声処理の実装アイディアをデモ・プロトタイピングするのになかなかハマる技術スタックではないでしょうか。 Webブラウザから利用できる物体検知デモの例。実行中に閾値をスライダーで変えられる。オンラインデモ🎈 同様にスタイル変換デモの例。実行中にモ
はじめに 当ポストは、低遅延配信の技術であるWHIP(WebRTC-HTTP Ingestion Protocol)を自分で動かしてみたい方へ向けた記事となります。 WebRTCを利用した配信映像の集信プロトコルであるWHIPは現在Internet-Draftではありますが、配信技術者やWebRTC技術者の注目を得て、実際に動かせる環境が整ってきました。 当ポストでは、WHIPが動く環境を作り、自前のWebRTCスタックをWHIPで使う簡単な方法を紹介します。 とはいえInternet-Draftということもあり、「WebRTCなら聞いたことあるけど、WHIPって何?配信とWebRTCが関係あるの?」という方も多いと思いますので、最初はWHIPの紹介から入りたいと思います。 WHIPとは WHIPは、WebRTCを利用したインジェストのためのHTTPSベースのシグナリングプロトコルです。
JavaScript Registry(JSR)やDenoの開発者であるLuca Casonato氏が、Google純正のウェブブラウザであるGoogle ChromeにはGoogle関連のウェブサイトしかアクセスできないAPIがプリインストールされていると指摘しています。 Casonato氏によると、Google ChromeはすべてのGoogle関連サイトにシステムおよびタブ上でのCPU使用率・GPU使用率・メモリ使用率といった情報への完全なアクセス権限を付与しています。他にも、より詳細なプロセッサ情報へのアクセス権限や、ログを記録するバックチャンネルへのアクセス権限も付与しているそうです。これらを実現するAPIは、他のウェブサイト向けには公開されておらず、Googleが自社サイトでのみ利用しているものであると、Casonato氏は指摘しています。 So, Google Chrome
マルチメディアフレームワークの「FFmpeg」に、ブラウザやアプリ間でリアルタイムの映像・データ通信を可能にする「WebRTC」(WHIP)対応の低遅延ストリーミング機能が統合されました。 git.ffmpeg.org Git - ffmpeg.git/commit https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/167e343bbe75515a80db8ee72ffa0c607c944a00 WHIPはWebRTCを通じて超低遅延で映像を配信するための標準プロトコルです。WebRTCはもともとライブ会議などの超低遅延・双方向通信に使われてきましたが、プロトコルが複雑でアップストリームの配信には不向きでした。それを簡単にしたのがWHIPです。 従来のFFmpegは配信ソフト「OBS」などで採用される通信プロトコル「RTMP」やHLSによる数秒
時雨堂では WebRTC を CLI で利用できる WebRTC ネイティブクライアント Momo というのを OSS (Apache-2.0) で公開しています。 今回 Momo で Intel VPL (ハードウェアアクセラレーター) と YUY2 (無圧縮形式) で 720p @ 120fps を実現できる Elgato Facecam MK.2 という約 2 万の Web カメラを利用して、WebRTC で AV1 で 720p @ 120 fps を実現しました。 これは時雨堂の WebRTC SFU Sora 経由でブラウザに配信した画像です。 仕組み自体は至ってシンプルで Momo に YUY2 で受け取った映像を NV12 に変換して Intel VPL で AV1 形式に変換する仕組みを追加するだけです。 実は元々は Intel VPL は H.265 であれば、 YUY
AyameというWebRTC Signaling Serverの実装がある。 Web側のSDKとサーバー側の実装が両方公開されており、プロトコルの仕様も文章化されている。 GitHub - OpenAyame/ayame-web-sdk: Ayame Web SDK GitHub - OpenAyame/ayame: WebRTC Signaling Server Ayame GitHub - OpenAyame/ayame-spec: WebRTC Signaling Server Ayame Spec そして今回、Ayame互換のプロトコルを持つWebRTC Signaling Server "ayu" を開発した。 github.com 動機 Ayameはサーバー側も含めてオープンな実装があるのになぜ新しく互換サーバーを作ったのか。 大きく分けて2つの理由がある。 ステートレス カス
初めましてこんにちは、今年の4月から新卒でフロントエンド開発部に入社した cw-suetake 🐧です。 いきなりですが、WebRTCを利用したビデオチャットなどを開発しているとE2Eテストがほしくなってきませんか? 開発者一人で開発していると動作確認のために複数のブラウザを起動したり、PCにたくさんのwebカメラやらマイクやらを接続して…それぞれのウィンドウで各種機能が動くか確認して…とにかく動作確認ひとつにしてもやることが多くなりがちです。 そうなってくると、ある程度の動作検証はE2Eテストに任せて楽をしたくなるものです。しかしWebRTCはブラウザ側に実装されているAPIに強く依存していますし、そもそもどうやってカメラやマイクが正しく動作することを保証すればいいのでしょうか?そんな悩みに対しての自分なりの案をご紹介します。 テスト対象 音声とカメラ映像を送受信してオンラインコミュニ
DiscordやSlackなどチャットやビデオ通話を主目的としたソフトウェアは数々存在しますが、オープン標準かつ軽量なリアルタイム通信プロトコルMatrixを採用したチャットソフトウェアが「Element」です。Elementはエンドツーエンド暗号化を用いたセキュアなチャットが行えるというだけでなく、ビデオ通話まで可能ということなので、実際に使ってみました。 Secure messaging app | End-to-end encrypted messenger https://element.io/personal というわけで、Elementを実際に使ってみます。Elementはウェブブラウザ版・iOS版・Android版・PCソフトウェア版が存在するので、それぞれを実際に使ってみます。 ・目次 ◆ウェブブラウザ版 ◆iOS版 ◆Android版 ◆PCソフトウェア版 ◆ウェブブラウ
OpenAIが「OpenAI o1(正式リリース版)」のAPIを公開しました。合わせて、AIとの音声会話機能を提供する「Realtime API」のアップデートや、モデル微調整機能のアップデート、GoライブラリおよびJavaライブラリのリリースも発表されています。 OpenAI o1 and new tools for developers | OpenAI https://openai.com/index/o1-and-new-tools-for-developers/ Our reasoning model @OpenAI o1 is now in the API! It comes with function calling, developer messages, Structured Outputs, and vision. 🍓 We also shipped WebRTC s
この記事は NTTコミュニケーションズ Advent Calendar 2023 の15日目の記事です。 この記事では、ChatGPT と 音声認識モデルの Whisper を用いた発音練習アプリケーションをご紹介します。 ChatGPT に読み上げる文章を考えてもらい、その文章の読み上げた音声を Whisper で文字起こしします。 正確に発音できていれば、正確に文字起こしできる、という考えから、 原稿と文字起こし結果を比較すれば発音練習に使えるのではないかと考えました。 実際に使ってみた結果、発音のどこが悪かったのかといったフィードバックはもらえませんが、 自分の発話した音声に対して評価がつくだけでも、結構楽しく練習できると感じました。 音声認識を活用したアプリケーションは、一般に音声認識精度がネックになると思いますが、 このアプリケーションは音声認識精度が100%ではないことを逆手に
ウェブブラウザ「Firefox 106」の正式版が公開されました。記事作成時点ではmacOS限定ながら画像内のテキストを抽出する機能が追加されるなど、ユーザーが直接触れる機会が多くなりそうな数々の機能が導入されています。 Firefox 106.0, See All New Features, Updates and Fixes https://www.mozilla.org/en-US/firefox/106.0/releasenotes/ ◆画像内のテキスト抽出 macOS 10.15(Catalina)以降で、選択した画像からテキストを抽出できるようになります。テキストの抽出を行うには、テキストを含む画像を右クリックし、表示されるポップアップメニューから「Copy Text from Image」を選択します。 抽出されたテキストは共有・保存・検索するためにクリップボードにコピーされ
ユーザーのウェブブラウザ間でビデオやオーディオ通話をする際のタイムラグを軽減するために使用される「WebRTC」の機能により、ユーザーのローカルIPアドレスが悪意のあるサイトに取得される危険性があることがかねてから報告されています。新たに、IPアドレスの漏えいを体験できるテストサイトが公開されました。 WebRTC Local IP Leak Test 🍌 - github.com/niespodd/webrtc-local-ip-leak https://niespodd.github.io/webrtc-local-ip-leak/ GitHub - niespodd/webrtc-local-ip-leak: Oh no, stop this. You can see my local IP address 😲! Use `foundation` attribute agains
前回のechoサンプルを少し改良しました。 前回はechoサンプルを動くようにしましたが、 今回はHTML側に切断処理を入れ、WebTransportのセッションが閉じられた時にQUICのイベントログを出力するようにしました。 今回はそのログも合わせてプロトコルを理解していきます。 ソースコードはこちら WebTransport? HTTP/3?? QUIC??? 何それおいしいの? WebTransportに何となくワクワクと闇の気配を感じている皆様こんにちは。 今回は前回のechoサンプルとドラフトを睨めっこしながらプロトコルについて理解していきたいと思います。 ここではChrome M97に実装されている WebTransport over HTTP/3について調べていきます。 どうしてWebTransportが必要なの? ブラウザで双方向通信がしたい けどWebSocketはTCP
Intel Ignite 2023で優勝! AV1やH.266を超える圧縮率を実現するDeep Renderの「AIベースの動画圧縮技術」って何?:Intel Ignite 2023(1/4 ページ) 有望なベンチャー企業を支援すべく、Intelは2019年から「Intel Ignite」という支援プログラムを展開している。支援対象になれば同社から数百万ドルの資金援助を受けられるということもあって、多くのスタートアップ企業がこのプログラムに参加/応募している。 →Intel Ignite 9月に行われたイベント「Intel Innovation 2023」では、本プログラムの年度決勝に相当する「2023 Intel Startup Innovator Award」の表彰式が開催された。このアワードは、2023年度にIgniteに応募したベンチャー企業の中から選出された“トップ3”の優勝者を
Apple’s new iCloud Private Relay service allows users to hide their IP addresses and DNS requests from websites and network service providers. In this article, we’ll demonstrate how this security feature can be circumvented and discuss what users can do to prevent their data from being leaked. You’ll need to turn on iCloud Private Relay to test the vulnerability. At the moment iCloud Private Relay
「Proxying Listener UDP in HTTP」という提案仕様がIETFに提出されている。 これは、HTTP/3のCONNECT-UDPを介してWebRTC通信を可能にするための提案である。まだ議論の呼び水と鳴るdraftであるため、ここから仕様は大きく変わると思うが、ざっと眺めていく。 HTTP/3のCONNECT-UDP 本論に入る前に、まずCONNECT-UDPについて説明します。 IETFではすでに「Proxying UDP in HTTP」という仕様が議論されている。これが通称CONNECT-UDPと呼ばれているものである。実は、AppleのPrivate Relayでもすでに使用されているものである。 これは、Proxyと確立したHTTP/3コネクションをトンネリングしてUDPパケットを中継させる機能です。 この通信は第三者からはただのHTTP/3通信としてか観測
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く