Google、HTTPを置き換えるプロトコルに取り組む
原文(投稿日：2009/11/13)へのリンク GoogleがSPDYを提案した。これはSSLの上で動く新しいアプリケーションプロトコルであり、レイテンシが大きいとされるHTTPを置き換えるものだ。彼らはすでに、SPDYに対応したWebサーバとChromeブラウザによるプロトタイプを開発しており、Webページを2倍高速にロードできるという。 少し前、Googleはインターネットを高速にすることを目的として、「Webを高速化しよう」というイニシアチブを立ち上げた。このイニシアチブのスコープは、高速なWebサーバの開発から高速なブラウザの開発まで、広範囲に及んでいる。例えば、Page Speedは、Webページを改善して高速なダウンロードを実現するためのツールだ。世界中の開発者がWebサイトを高速化できるよう、Googleは様々なツールをオープンソースにして、チュートリアルを公開した。 しかし
リアルタイムな更新通知プロトコル「PubSubHubbub」 | gihyo.jp
Push型Webサービスを実現する方法が最近また注目を集めています。数年前にはCometという技術が注目され、チャットサービスなどに使われました。そしてTwitterのようなリアルタイムな情報をいち早く取得できるよう「Web Hooks」というしくみが考えられ、Google Codeやはてなブックマークで採用されています。 この記事で取り上げている「PubSubHubbub」はWeb Hooksと同様のモデルを使ったプロトコルです。その名のとおり、Publisher（フィード側）とSubscriber（購読者側）の間にHubを置くことで、Publisher-Subscriber間のやりとりをHub側に任せるようにします。 ブログサービス、RSSリーダサービスなどがPubSub Hubbubに対応することで、ブログ記事を更新すると即座にRSSリーダに反映するようになります。現在はGoogle
Big Sky :: githubが使っているBERT-RPCを理解した。
githubが高速化に成功した様です。 How We Made GitHub Fast - GitHub Now that things have settled down from the move to Rackspace, I wanted to take some time to go over the architectural changes that we’ve made in order to bring you a speedier, more scalable GitHub. ... For our data serialization and RPC protocol we are using BERT and BERT-RPC. http://github.com/blog/530-how-we-made-github-fast データのシリアライズおよびRPC(リ
「テキストプロトコルは遅くないよ」という話 - kazuhoのメモ置き場
「バイナリプロトコルは速い」「テキストプロトコルは遅い」という言説を、ときおり目にするけど、それって本当なのか。個人的には、それって昔の話だと思ってる。 SMTP みたいな、ペイロードについてもターミネータ（とエスケープ）を使うプロトコル*1は確かに遅い。で、FTPプロトコルでは、大容量のデータを「高速」に転送するために、制御用のTCPコネクションと転送用のコネクションを分けたりしてた。 だけど、HTTPプロトコルは、テキストプロトコルだけど、ペイロードについてはターミネータを使わない。keep-alive を行う際には、Content-Length ヘッダ（あるいはchunkedエンコーディング）を使うことで、ペイロードのパース／変換処理を不要にしている。別の言い方をすると、テキストプロトコルだからと言って、バイナリプトロコルよりペイロードの処理時間が長くなるとは限らない。HTTP 以降
Big Sky :: ReverseHttpで誰よりも速く「はてなブックマーク」に反応するツール書いた。
ReverseHttp面白いですね。 ReverseHttp Tunnel HTTP over HTTP, in a structured, controllable, securable way. Let programs claim part of URL space, and serve HTTP, all by using an ordinary HTTP client library. http://www.reversehttp.net/ ただ勘違いされやすいのが「何がReverseなの」という部分。通常ブラウザからリクエストが送信され、それに対する応答がサーバから返されます。ReverseHttpはサーバで何かアクションが起きた場合に、ブラウザ側がその通知を受信する...なんて事が出来るプロトコルです。仕組みはcometというlong pollに似た仕組みで、サイトのdemo
Google Reader、リアルタイムフィード技術を採用
米Googleは8月5日、RSSリーダー「Google Reader」に、リアルタイムなフィード配信を実現する配信／購読用プロトコル「PubSubHubbub」を採用したと発表した。 PubSubHubbubはGoogleの社員であるブラッド・フィッツパトリック氏らが“20％の自由時間”を利用して作成したAtomおよびRSSの機能拡張として使うオープンソースのプロトコル。RSSは、従来のポーリングによる方法では配信にタイムラグが生じるが、PubSubHubbubでは配信サーバと購読者の間にハブを設置し、フィードをプッシュする仕組みにより高速化し、ほぼリアルタイムでフィードできるとしている。 フィードアグリゲーターのFriendFeedがPubSubHubbubを採用しており、ユーザー同士がお互いのアクティビティをほぼリアルタイムで把握できているという。
なぜプロトコル記述言語はDSLでなければならないのか - .mjtの日記復帰計画
http://shinh.skr.jp/m/?date=20081006#p02 とおもったけど elf.py とか見ると結構コード入ってていまいち DSL ぽくないな… ですよねー という引用は全く関係なく自分の研究の話(我田引水) そもそもプロトコル記述言語とは何か 世間的に流行しているものでは無い(と思う)ので、いろいろな解釈が渦巻く。 C言語のstructに相当するものが記述できる XCB - http://xcb.freedesktop.org/ - XMLでX11のプロトコルを記述。 テンプレートマッチなどによりプロトコルの動作を記述できる prolac Preccs プロトコルそのものを記述する Sun-RPCのXDR ASN.1 pretty-printer Wiresharkのdissector 個人的に研究しているのは最初。 XCBはX11プロトコル専用なので、汎用化
オープンプロトコルのOAuthに脆弱性、Yahoo!やTwitterなどに影響
TwitterやYahoo!、GoogleなどがAPIに採用している「OAuth」に脆弱性が見つかった。 APIアクセス権の譲渡に使われているオープンプロトコルの「OAuth」に脆弱性が見つかった。OAuthを採用しているTwitterやYahoo!、Googleなどは、一時的にOAuthを無効にするなどの措置を取っている。 OAuthが4月23日付で公開したアドバイザリーによると、この脆弱性は「OAuth Core 1.0」のプロトコルに存在する。 攻撃者はまず正規のコンシューマーサイトにログインしてOAuth認証プロセスを開始し、サイトのリダイレクトに従って認証を受ける代わりに、Request Tokenとして発行された認証リクエストURIを保存する。次いでユーザーをだましてその認証リクエストURIで構成するリンクをクリックさせ、そのユーザーの保護されたリソースへのアクセスを許可させる
Apache Avro™ 1.8.2 Specification
order: specifies how this field impacts sort ordering of this record (optional). Valid values are "ascending" (the default), "descending", or "ignore". For more details on how this is used, see the the sort order section below. aliases: a JSON array of strings, providing alternate names for this field (optional). For example, a linked-list of 64-bit values may be defined with: { "type": "record",
VMware社がMicrosoft RDPに代わるプロトコルを（ちょっと）プレビュー（20090303-5） | virtualization.info
VMware社が、同社のVDI環境で真っ先に選ばれるリモートデスクトッププロトコルの座からMicrosoft RDPを引きずり下ろすべく懸命に開発を進めていることは公然の秘密だ。 同社は2007年末、新標準である「Net2Display」（これまでのところは日の目を見ていない）の開発を目指すVESA委員会に既に参加していた。 また、当時のVMworld 2008で、同社は（専用のグラフィックスカードにしか対応していなかった）PCoIPプロトコルのソフトウェア版を開発する技術提携を新興企業のTeradici社との間で発表している。 そして先週、VMworld Europe 2009（virtualization.infoによる第1日および第2日の速報参照）の開催中に、VMware社はそのソフトウェアインプリメンテーションのアルファ版を公開する見通しだったが、代わりに披露されたのが既存の「Te
[Think IT] 第4回：OpenIDの仕様を改めて復習してみよう (1/3)
OpenIDの仕様を改めて復習してみよう 本連載ではPHPによるOpenIDのサンプルを使って、実際に「Consumer」や「Identity Provider（以下、IdP）」を動かしながら、その仕組みについて解説してきました。かなり駆け足で紹介してきたため、今回はこれまでの解説を踏まえながら改めてOpenIDについておさらいします。 OpenIDでIdPが受け付けるアクセスには「associate」と「checkid_immediate」「checkid_setup」「check_authentication」の4つのモードがあります。これらは認証のたびにすべてが呼び出されるのではなく、状況によって選択されます。 まず「associate」では、アソシエーションハンドルとその有効期限、共通暗号鍵がIdPからConsumerに渡されます。アソシエーションハンドルは有効期限の間は再利用可能
ソフトウェア分野の研究開発 / RFC 5023 Atom Publishing Protocol 日本語訳 | Ricoh Japan
この文書は RFC 5023 The Atom Publishing Protocol を, BCP78によって付託された権利に基づいて日本語に翻訳したものです。 翻訳には誤りがある可能性があります。この翻訳の正確性は保証しません。 翻訳についてのお問合せ先：（SSL対応フォーム） （非SSL対応フォーム） 翻訳者一覧 株式会社リコー 山本陽平 日野原寛 高桑寿一 中川勝樹 沖田邦夫 井上浩一 兵清弘 リコーソフトウエア株式会社 福田朋紀 更新履歴 2008-01-07 日外アソシエーツ株式会社 久我様の指摘を受け 9.7 の訳文をわかりやすく、11.2 の抜けを修正 2007-12-06 9.6、9.7.1、9.7.2、10 の誤記、表記ぶれを修正 2007-11-08 エヌ・ティ・ティ・コミュニケーションズ株式会社 朝倉様の指摘を受け 9.3/9.4 の誤訳を修正 2007-11-0
mixi Engineers’ Blog » OAuthは熱いかも？な件に関して
お久しぶりです、最近はすっかり寒くなってきましたねー。原宿のオフィス環境に最近慣れてきたトールマエサカです。さておき、今日は認証API系のお話をしたいと思います。 OAuthとは? OAuthとは、最近注目されているウェブ上での認証プロトコルの事です。1.0プロトコルの最終ドラフトが、今月リリースされ、良い機会なのでエンジニアブログに書いてみました。 このエントリーを書いている課程で資料を検索してみたらまちゅさんが大変素晴らしい記事： WebAPI のアクセス制御に使える OAuth という仕様 OAuth の Auth は認証？認可？ (私もそう思う) を既に書かれている事に気がついたので私は軽くなめる程度にします。 で、実際にOAuthがどういう風に役に立つかというと、例えばウェブサービスAがウェブサービスBから、サービスBでのユーザの認証情報 (idとかpassword) を問わずに
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://jp.techcrunch.com/2009/08/06/20090805google-reader-speeds-up-sharing-with-pubsubhubbub/
pubsubhubbub - Google Code
サービス終了のお知らせ
Adobe社、Flashプラットフォームで使用しているリアル・タイム・メッセージング・プロトコル(RTMP)の仕様を近く公表予定
大发net手机版网页版登录-大发888官方指定下载网址
Studying HTTP
