タグ

関連タグで絞り込む (44)

タグの絞り込みを解除

WebSocketとあとで読むに関するItisangoのブックマーク (7)

  • A Complete Guide to IoT Protocols & Standards In 2023

    Itisango
    Itisango 2021/08/31
    “IoT data protocols (Presentation / Application layers) Network protocols for IoT (Datalink / Physical layers)”
    リンク

  • Oracle Fusion Cloud IoT Intelligent Applications向けのデバイス接続ガイド

    IoTでの通信に最適で適切なその他のHTTP以外に、メッセージ・キューの遠隔測定トランスポート(MQTT)、制約付きアプリケーション・プロトコル(CoAP)、WebSocket、Extensible Messaging and Presence Protocol (XMPP)、およびAdvanced Message Queuing Protocol (AMQP)もあります。 インターネットを介したREST接続性は、IoTデバイスの通信アーキテクチャとして使用されます。 通常、IoTデバイスはリソース制約を受け、このタイプの通信では、データ損失またはメモリー量の高い要件が存在する場合があります。 または、MQTT、CoAP、XMPP、WebSocket、AMQPなど、有効なプロトコルがいくつかあります。

    Itisango
    Itisango 2021/08/31
    “MQTT、CoAP、XMPP、WebSocket、AMQPなど、有効なプロトコルがいくつかあります。”
    リンク

  • 100万回のWebSocket接続とGo | POSTD

    こんにちは。私はSergey Kamardin（セルゲイ・カマルディン）です。Mail.Ru（ロシアの電子メールサービス会社）で開発者をしています。 この記事では、どのように私がGoを使って高負荷対応のWebSocketサーバを開発したかについて説明したいと思っています。 パフォーマンス最適化のアイデアやテクニックを通じて、WebSocketの知識はあるもののGoについてはほとんど知らないという方のお役に立てれば幸いです。 1. はじめに まずは開発に至った経緯について、どうして私たちがこのサーバを必要としたのかを説明しておきましょう。 Mail.Ruには多くのステートフルなシステムがあります。ユーザのeメール保存もその1つです。システム内、およびシステムイベントの状態変更を追跡する方法にはいくつかの種類がありますが、それらは主に状態変更に関するシステム通知、または周期的なシステムのポーリ

    100万回のWebSocket接続とGo | POSTD

  • サーバからクライアントに送信する技術 - WebSocketを中心に - Qiita

    Webでのプッシュ技術 HTTPはクライアント（ブラウザ）からリクエストしてサーバからレスポンスが返る一問一答型のプロトコルなので、基本的にはサーバ側からブラウザに新着情報をリアルタイムで通知（プッシュ）できるようにはできていません。 しかしそれでもプッシュをしたいという場合にどうするかという話が出てきます。やり方には以下のようなものがあります。 ポーリング クライアントからサーバに定期的に新着を問い合わせるようにします。 最も原始的かつ確実なやり方。欠点は、最大でポーリング間隔の分だけ通知が遅延しうることです。 ロングポーリング（“COMET”） ポーリングなのですが、問い合わせを受けたサーバは新着情報がなければレスポンスを返すのをしばらく保留します。 そのあいだに新着情報が発生すれば即座にレスポンスを返しますし、一定時間経過したら何もなかったとレスポンスを返しましょう。 飛び交う通信内

    サーバからクライアントに送信する技術 - WebSocketを中心に - Qiita

  • Docker と ECS と WebSocket で最強のリアルタイム・マルチプレイ環境を運用 | GREE Engineering

    概要 AWS ECS でマルチプレイゲーム用インスタンスの管理すると限りなく最強。 はじめに リアルタイム・マルチプレイゲームを作る時、まず考えられることは、あるプレイヤーの行動や状態が他のプレイヤーに伝わることではないかと思われます。しかし、スマートフォンアプリは不安定であったり、複数端末同士で(基地局やバックボーンを介さずに)物理的に直接接続することは出来ませんし、理論的にできたとしても、だいたい開発が進んでいくうちに排他制御の問題などで炎上、もしくはとん挫してしまいます。軽い気持ちでマルチスレッド処理をおこない事故る現象と全くおなじです。 もっとも簡単な解決方法としてはマルチスレッド処理のときようにクリティカルセクションを設けることです。ようはサーバを用意してそこで処理すれば、比較的容易に一意な結果が得られますし、接続に関する問題も起こりにくくなります。 長くなるので → http:

    Docker と ECS と WebSocket で最強のリアルタイム・マルチプレイ環境を運用 | GREE Engineering
    Itisango
    Itisango 2016/06/11
    あかん、この方面に対する知識が無さすぎる。
    リンク

  • [システム間連携]接続方向を逆転させるとうまくいく - Qiita

    システムAの更新内容を、別のサーバにあるシステムBにも反映させるためにデータ送る、というケースを考えます。 主流はWeb APIかMOMを使う方法かと思います。(俯瞰的な話は、20日目のこざけさんが書いてくれる、はず) しかし、A,B間で同時に一貫性を保たなくても良いケースは、企業間システム連携ではよくあります。 CAP定理でいうところの可用性＋分断耐性をとりにいくパターンです。が、最大数秒程度で結果整合性は保ちにいきます。 システム間の接続 非同期ながら、ほぼリアルタイムでデータを反映していくので、応答性の高い接続手段が求められます。だが中間経路をHTTPでないプロトコルを通すハードルが高かったり、ファイヤーウォールなどで長時間接続を切られたりする問題があるので、私はよくWebSocketを使います。 だいたいの構成は以下のようになります。同期エージェント間をWebSocketでつなぎ、

    [システム間連携]接続方向を逆転させるとうまくいく - Qiita

  • WebRTCによるビデオチャットサービスの開発 - Qiita

    はじめに Webで使えるビデオチャットサービスを開発しましたので、システム構成や使用したフレームワークやサービス、開発のポイントなどまとめてみました。 (去年にはQiitaの投稿を作っていたのですが、下書き保存したまま忘れて今頃の投稿になってしました。。) 月々のランニングコストは1000円以内、開発工数は1人月以内で作成しています。 WebRTCが出てきたおかげで、かなり容易にビデオチャットサービスが開発できるようになっていますので、よければ参考にしてください。 開発のポイント、コードだけでなく、開発の動機から、システム構成を決める為、開発前後に行ったビデオチャット関連の技術調査なども載せています。必要最小限の事だけ把握したい方はその辺りは読み飛ばしてください。 開発ビデオチャットサービス: ビデオチャッターズ (http://videochatters.net/) 開発動機 5～6年ぐ

    WebRTCによるビデオチャットサービスの開発 - Qiita
  • 1

お知らせ

もっと読む

公式Twitter

  • @HatenaBookmark

    リリース、障害情報などのサービスのお知らせ

  • @hatebu

    最新の人気エントリーの配信

はてなブックマーク

公式Twitter

はてなのサービス

  • App Storeからダウンロード
  • Google Playで手に入れよう
Copyright © 2005-2024 Hatena. All Rights Reserved.