クレジットカードの通信プロトコル ISO8583 と戦うSymfony Messenger et ses messages: à la queleuleu…. Et s’il était temps de grouper ?
Unofficial AirPlay Protocol Specification
Unofficial AirPlay Protocol Specification 1. Introduction 2. Service Discovery 2.1. AirTunes service 2.2. AirPlay Service 3. Photos 3.1. HTTP requests 3.2. Events 3.3. Photo Caching 3.4. Slideshows 4. Video 4.1. HTTP requests 4.2. Events 5. Audio 5.1. RTSP requests 5.2. RTP Streams 5.3. Volume Control 5.4. Metadata 5.5. AirPort Express Authentication 5.6. Remote Control 6. Screen Mirroring 6.1. HT
QUIC Geek FAQ (和訳) - yoya's diary
https://docs.google.com/document/d/1lmL9EF6qKrk7gbazY8bIdvq3Pno2Xj_l_YShP40GLQE/edit?pli=1#heading=h.h3jsxme7rovm の和訳 アドバイスを頂きました mumumu-tan さんに感謝します。 Experimenting with QUIC も併せてお読みください。 http://d.hatena.ne.jp/yoya/20130630/quic QUIC Geek FAQ QUIC Geek FAQ (for folks that know about UDP, TCP, SPDY, and stuff like that) QUIC Geek FAQ (UDP, TCP, SPDY といった要素が分かる人向け) What is QUIC? QUIC とは何ですか？ QUIC is
Experimenting with QUIC
$200K 1 10th birthday 4 abusive ads 1 abusive notifications 2 accessibility 3 ad blockers 1 ad blocking 2 advanced capabilities 1 android 2 anti abuse 1 anti-deception 1 background periodic sync 1 badging 1 benchmarks 1 beta 83 better ads standards 1 billing 1 birthday 4 blink 2 browser 2 browser interoperability 1 bundles 1 capabilities 6 capable web 1 cds 1 cds18 2 cds2018 1 chrome 35 chrome 81
Googleの新プロトコルQUICを試す - ぼちぼち日記
1.QUIC仕様の公開 以前、「Googleが仕掛ける新プロトコルQUICとは何か」のブログエントリーを書いたのが2月末の事でした。それから4か月経ち、今朝Googleが初めてQUICの公表(Chromium Blog: Experimenting with QUIC)を行いました。 IE11のSPDY/3対応が判明した直後でした。なんというタイミングでしょうか。 また、近いうち（来週？）には HTTP/2.0 の Implementation Draft が公開される予定です。8月上旬には、GoogleやMicrosoft等が集まって初めての HTTP/2.0 の相互接続試験を行う予定です。ただ今HTTP関連のプロトコルが急激に進化する真っ最中です。目が離せません。 2. で、QUICとは何なのか？ 先のChromium BlogのエントリーでQUICは、 「Quick UDP Inte
Googleが仕掛ける新プロトコルQUICとは何か - ぼちぼち日記
まずは免責事項。 1.Disclaimer 本ブログの記載内容は、筆者が独自に QUIC に関する Chromium のソースを分析し、検証した結果です。 QUICに関するGoogle からの公式な技術資料は現状公開されていません。 今後、QUICの技術仕様の公表で本ブログの記述内容が不十分だったり、誤っている可能性があります。ご理解の上お読みください。 (注： 2013年6月27日に Google は正式に QUIC 仕様を公開しました。「Experimenting with QUIC 」 本ブログの内容は大筋では間違っていませんが、当時の解析漏れやその後の開発等により、細かいところで異なっていたり、説明が大きく不足している部分もあります。お読みになる際はご注意ください。) 2. はじめに、 Googleがまたまた新しいプロトコルの実装を始めました。Web表示の高速化を目指した SPDY
IMessage - IMFreedom Knowledge Base
IMessage http://en.wikipedia.org/wiki/IMessage Information on this page is based on my examination of the Messages Beta application for Mac OS X. The "client" works with three processes: iChat, imagent and applepushserviced. iChat (which is now Messages) shows the UI, but does not handle anything protocol specific, that's what imagent does (so the user stays logged in if iChat isn't running). Howe
Surfin' Safari - Blog Archive » Announcing Remote Debugging Protocol v1.0
It has been almost a year since we announced the support for WebKit remote debugging. It is now officially supported by BlackBerry PlayBook and in Chrome for Android. Latest version of Chrome introduces new extensions API that exposes it to the in-browser clients as well. Today we are happy to announce the v1.0 of the remote debugging protocol. We commit to supporting it and maintain its backward
TCPに代わる通信プロトコル「CurveCP」、Chromiumで取り込み | エンタープライズ | マイコミジャーナル
Google Chrome runs web pages and applications with lightning speed. CurveCPの初期実装がChromiumに追加された。ただし、まだ完全な実装ではないと説明されている。CurveCPは2010年12月28日にChaos Communication Congressで発表された新しいトランスポートプロトコル。現在策定が進められている段階で、2月21日に最初の実装系となる「NaCL(Networking and Cryptography library)」が公開されたばかり。Chromiumにおける実装はかなり素早い動きといえる。 CurveCPはTCPとよく似たプロトコルとされているが、パケットを楕円曲線暗号で暗号化して通信するという特徴がある。CurveCPで使われている暗号化ツールはDNSCurveで使われているのと
SPDY
SPDY is deprecated. This page is out of date. SPDY was an experimental protocol for the web with the primary goal to reduce latency of web pages. Its successor is HTTP/2. Documentation SPDY: An experimental protocol for a faster web SPDY protocol specification Server Push and Server Hint Research An Argument For Changing TCP Slow Start - Mike Belshe 01/11/10 More Bandwidth Doesn't Matter (much) -
グーグルが高速プロトコル「SPDY」をChromeブラウザで有効化。Gmailなどで利用を開始していた
グーグルが高速プロトコル「SPDY」をChromeブラウザで有効化。Gmailなどで利用を開始していた グーグルがより速いWebを実現するために、HTTPを高速化した新プロトコル「SPDY」を開発中であることは、昨年夏に公開した記事「グーグルがWebを高速化するために何をしているか」で紹介しました。 SPDYの話題はその後ほとんど見かけなくなりましたが、グーグルはそのSPDYをChromeに実装し、同社のサービスで利用していることがニュースサイトConceivably Techの記事「Google Chrome Gets SPDY – And An Onscreen Keyboard」で指摘されています。 なぜグーグルはひっそりとSPDYを有効化したのだろう？ SPDYとは従来のWebのプロトコルであるHTTPを改良し、毎回同じ情報がやりとりされるヘッダの情報を圧縮したり、リクエストの回数
フェイスブック、ミクシィ、グリーで使われている OGP (Open Graph Protocol) とは何か - IT戦記
みなさん、こんにちは お元気ですか？僕は元気です。 さて 最近よく、「いいね！」ボタンや「ミクシィチェック」ボタンによって、ウェブページを紹介し合う文化が少しずつ定着してきたなーと思います。 そんな中で、今後重要になってくるんじゃないかと思われる OGP （Open Graph Protocol）と言われる仕様があります。今日はそのことについて書いてみたいと思います。 OGP? おーじーぴー？？とはなんでしょうか。 OGP とは 簡単に言うと「このウェブページは何のことを書いているか」という情報を、プログラムから読める形で HTML に付加する記述方法のことです。 まあ、普通のウェブページは人間が読めばだいたい何のことが書いてあるか分かりますよね。 ですが、プログラムは人間ほど頭が良くないので、そのウェブページ内の文章だけではそのページが何のことについて書かれているページなのか正確に識別す
WebSocket Protocol Updated
$200K 1 10th birthday 4 abusive ads 1 abusive notifications 2 accessibility 3 ad blockers 1 ad blocking 2 advanced capabilities 1 android 2 anti abuse 1 anti-deception 1 background periodic sync 1 badging 1 benchmarks 1 beta 83 better ads standards 1 billing 1 birthday 4 blink 2 browser 2 browser interoperability 1 bundles 1 capabilities 6 capable web 1 cds 1 cds18 2 cds2018 1 chrome 35 chrome 81
MessagePack-RPCのプロトコル仕様（ドラフト）と実装例 - Blog by Sadayuki Furuhashi
以前に書いた MessagePack RPC プロトコル は少し古くなってしまったので、ここでまとめ直しておこうと思います。 MessagePack-RPCのプロトコルは、非同期型の呼び出しができる点（非同期プロトコル）が大きな特徴となっています。複数のサーバが相互に通信し合ったり、通信と計算をオーバーラップさせて高速化を図ったりするような、高度なネットワークアプリケーションを実装しやすくなります。 RPCライブラリと言うよりも、シンプルな非同期メッセージングライブラリと言えます。 ここではMessagePack-RPCのプロトコル仕様と、以上の特徴を活かせるような実装例も合わせて紹介します。 基本仕様：MessagePack-RPC specification version 0.1 MessagePack-RPCのプロトコルは、メソッドの呼び出すRequestメッセージと、それに対する
memcachedプロトコルについて
※ memcachedプロトコルの仕様書は以下にあります。 http://code.sixapart.com/svn/memcached/trunk/server/doc/protocol.txt データの保存を行うコマンド(set,add,replace,append,prepend)は、以下のような文法となります。 <コマンド> <key> <flags> <exptime> <bytes> <data> <key>は保存するためのキー名を指定します。実装によっても異なりますが、最大長は250byteです。 <flags>はアプリケーション特有の32bitの値(0〜4294967295)を指定することができ、データの取得時に格納した時の値が返されます。 <exptime>はデータの有効期間を秒数で指定します。指定した時間経過すると、自動的にキーが削除されます。0を指定すると自動削除され
spec [MessagePack]
MessagePack saves type-information to the serialized data. Thus each data is stored in type-data or type-length-data style. MessagePack supports following types:
バイナリシリアライズ形式「MessagePack」 - Blog by Sadayuki Furuhashi
Googleが公開したバイナリエンコード手法であるProtocol Buffersは、クライアントとサーバーの両方でシリアライズ形式を取り決めておき（IDL）、双方がそれに従ってデータをやりとりするようにします。 この方法では高速なデータのやりとりができる反面、IDLを書かなければならない、仕様を変えるたびにIDLを書き直さなければならない（あらかじめしっかりとIDLを設計しておかないとプログラミングを始められない）という面倒さがあります。 ※追記：Protocol BuffersのデシリアライザはIDLに記述されていないデータが来ても無視するので（Updating A Message Type - Protocol Buffers Language Guide）、仕様を拡張していっても問題ないようです。 一方JSONやYAMLなどのシリアライズ形式では、何も考えずにシリアライズしたデータ
コメント分散問題は“サーモン・プロトコル”で解決!? － ＠IT
2010/02/26 “ソーシャル”と名の付くサービスが複雑で嫌になったことはないだろうか？ 複雑さの原因はいくつかあると思うが、会話の流れが多数のサイト（サービス）に分散してしまっていることも大きな原因の1つに違いない。特にサービス間が連携しているような場合、どこで誰がどのようにコメントを付たのか、追いきれない。 例えば、次のような問題がある。 ある時、Facebookがタイムラインを取り入れ、Twitterとの連携も可能となった。普段はTwitterしか使っていないのに、うっかりFacebookのほうにも自分のフィードを流していたために、Facebookのほうでコメントが付くようになってしまう。これはTwitter側で見えない。 こうした問題は、自分がどこのブログにコメントしたか忘れることを前提とした“通りすがりコメント”というものも生み出してきた（参考記事：「通りすがり」コメントの終
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TechCrunch
yebo blog: uTPのソースコードをオープンソースで公開