タグ

protocolに関するakaneharaのブックマーク (6)

  • Quake 3 Source Code Review: Network Model

    Quake 3 Source Code Review: Network Model (Part 3 of 5) >> The network model of Quake3 is with no doubt the most elegant part of the engine. At the lower level Quake III still abstract communications with the NetChannel module that first appeared in Quake World. The most important thing to understand is: In a fast paced environment any information that is not received on first transmission is not

  • memcachedバイナリプロトコルは同期プロトコルを禁止するべき - Blog by Sadayuki Furuhashi

    現状のmemcachedのバイナリプロトコルのクライアント(=libmemcached)は、リクエストの順番通りにレスポンスが返ってくることを期待しており、これはmemcachedバイナリプロトコルを「汎用的なkey-valueベースの分散ストレージのためのプロトコル」として考えると、ひどい実装である。 そのような実装は最適化の余地を大幅に制限してしまい、性能とスケーラビリティが悪化する。memcachedの仕様書は、そのようなクライアントの実装はバグであると明示するべきである。 現状のmemcachedクライアントの実装の問題点と、その解決策について述べる。 同期プロトコルと非同期プロトコル ネットワークプロトコルは以下の2つの種類に分けられる: 同期プロトコル リクエストの順番通りにレスポンスを返す(リクエストの順番とレスポンスの順番が同期している) 非同期プロトコル リクエストした順

    memcachedバイナリプロトコルは同期プロトコルを禁止するべき - Blog by Sadayuki Furuhashi
  • https://github.com/memcached/memcached/blob/master/doc/protocol.txt

    https://github.com/memcached/memcached/blob/master/doc/protocol.txt
  • TCPの状態遷移 - Qiita

    TCPの状態一覧 LISTEN(聴取) TCPモジュールはリモートホストからのコネクション要求を待っている。パッシブオープンの後で入る状態と同じ。 SYN-SENT(SYN送信済み) TCPモジュールは自分のコネクション要求の送信を終え、応答確認と対応するコネクション要求を待っている。 SYN-RECEIVED(SYN受信済み) TCPモジュールは同期(SYN)セグメントを受信し、対応する同期(SYN/ACK)セグメントを送って、コネクション応答確認を待っている。 ESTABLISHED(確立済み) コネクションが開かれ、データ転送が行える通常の状態になっている。受信されたデータは全てアプリケーションプロセスに渡せる。 FIN-WAIT-1(FIN待機1) TCPモジュールはリモートホストからのコネクション終了要求か、すでに送った終了要求の応答確認を待っている。 FIN-WAIT-2(FI

    TCPの状態遷移 - Qiita
  • MQTT V3.1 プロトコル仕様

    • • • • • • o o o • • © 1999 • o • o o o o o • o o o o o o o o o o o o o o • o o o • • • • • • • • do digit = X MOD 128 X = X DIV 128 // if there are more digits to encode, set the top bit of this digit if ( X > 0 ) digit = digit OR 0x80 endif 'output' digit while ( X> 0 ) multiplier = 1 value = 0 do digit = 'next digit from stream' value += (digit AND 127) * multiplier multiplier *= 128 while ((d

  • 「テキストプロトコルは遅くないよ」という話 - kazuhoのメモ置き場

    「バイナリプロトコルは速い」「テキストプロトコルは遅い」という言説を、ときおり目にするけど、それって当なのか。個人的には、それって昔の話だと思ってる。 SMTP みたいな、ペイロードについてもターミネータ(とエスケープ)を使うプロトコル*1は確かに遅い。で、FTPプロトコルでは、大容量のデータを「高速」に転送するために、制御用のTCPコネクションと転送用のコネクションを分けたりしてた。 だけど、HTTPプロトコルは、テキストプロトコルだけど、ペイロードについてはターミネータを使わない。keep-alive を行う際には、Content-Length ヘッダ(あるいはchunkedエンコーディング)を使うことで、ペイロードのパース/変換処理を不要にしている。別の言い方をすると、テキストプロトコルだからと言って、バイナリプトロコルよりペイロードの処理時間が長くなるとは限らない。HTTP 以降

    「テキストプロトコルは遅くないよ」という話 - kazuhoのメモ置き場
  • 1