タグ

protocolに関するstarsky5のブックマーク (13)

  • yebo blog: Google TalkでJingleをサポート

    2011/06/24 Google TalkでJingleをサポート Googleは、Google TalkのVOIP用シグナリング・プロトコルにJingle (XEP-166、XEP-167)をサポートすることを発表した[xmpp standard]。加え、多くのクライアントで利用可能なlibjingleというライブラリもリリースしている(BSDライセンス)。JingleはEMPP(Extensible Messaging and Presence Protocol)を、VoIPやビデオ会議などのマルチメディアの通話に使えるようP2Pのシグナリング制御を実装したプロトコル。マルチメディアストリームはRTPを使用し、必要に応じて、ICEを使ったNAT traversalも行われる。GoogleとXMPP Standards Foundationによって設計された。 投稿者 zubora 投

  • フェイスブック、ミクシィ、グリーで使われている OGP (Open Graph Protocol) とは何か - IT戦記

    みなさん、こんにちは お元気ですか?僕は元気です。 さて 最近よく、「いいね!」ボタンや「ミクシィチェック」ボタンによって、ウェブページを紹介し合う文化が少しずつ定着してきたなーと思います。 そんな中で、今後重要になってくるんじゃないかと思われる OGP (Open Graph Protocol)と言われる仕様があります。今日はそのことについて書いてみたいと思います。 OGP? おーじーぴー??とはなんでしょうか。 OGP とは 簡単に言うと「このウェブページは何のことを書いているか」という情報を、プログラムから読める形で HTML に付加する記述方法のことです。 まあ、普通のウェブページは人間が読めばだいたい何のことが書いてあるか分かりますよね。 ですが、プログラムは人間ほど頭が良くないので、そのウェブページ内の文章だけではそのページが何のことについて書かれているページなのか正確に識別す

    フェイスブック、ミクシィ、グリーで使われている OGP (Open Graph Protocol) とは何か - IT戦記
  • BitTorrentのファイル配信メカニズム - Emerge Technology

    Linuxのディストリビューションの配布などで配布サーバの回線速度などがボトルネックになり(図1)、円滑にファイルを配布することはコストがかかります。BitTorrent(図2)は配布者の負担を軽減して、素早くファイルを配信することを目的にBram Cohenによって開発されたP2Pソフトウェア(図3)です。 BitTorrentでは、トラッカーとよばれる全てのピアとピアのアップロード/ダウンロード能力、ファイルの取得状況を管理するサーバが存在します。一般的なP2PシステムではP2Pネットワーク内を検索してからファイルの取得という動作を行いますが、BitTorrentでファイルの検索という作業は行ないません。代わりにトラッカーにファイルを持っているピアを問い合わせます。ファイルを持っているピアの検索をクライアント・サーバで行うということで、従来の分類ではハイブリッド型P2Pシステムになりま

    BitTorrentのファイル配信メカニズム - Emerge Technology
  • MessagePack RPC プロトコル - Blog by Sadayuki Furuhashi

    ※2010-04-06追記:ここの内容は大体あっていますがもう古いです。MessagePack-RPCプロトコル仕様(ドラフト)と実装例 を参照してください。 名前は(仮)です。 現在クラスタ通信フレームワーク ccf というものを開発中で*1、MessagePack を使ったRPCプロトコルを使っています。プロトコルの仕様は JSON-RPC を元に MessagePack 用により高速性を重視したもので、とてもシンプルです。 1つの通信路(TCPコネクションなど)でRPCの遅延リターンができるように、メッセージにはシーケンス番号が入っています。応答を2回以上返してしまっても片方を無視できたり、RPC応答をRPC要求とは異なる通信路で返すことができるという利点もあります。 RPC要求 RPC要求は次の4つの要素からなる配列 [type, msgid, method, params] です

    MessagePack RPC プロトコル - Blog by Sadayuki Furuhashi
  • 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(リ

    Big Sky :: githubが使っているBERT-RPCを理解した。
  • tokuhirom blog

    Blog Search when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: ${entry.path} [in template "__entry.ftlh" at line 3, column 25] - Reached through: #include "__entry.ftlh" [in template "entry.ftlh" at

  • HTTPプロトコルパーサのオーバーヘッドは18%以下という話 - kazuhoのメモ置き場

    「テキストプロトコルは遅くないよ」という話 - kazuhoのメモ置き場に関するの具体的な話。 Kazuho@Cybozu Labs: 「サーバ書くなら epoll 使うべき」は、今でも正しいのかを書く際に自作したベンチマークツールがあるのですが、それを使ったベンチマーク結果をid:tokuhiromがhttp://d.hatena.ne.jp/tokuhirom/20091001/1254355956にまとめてくれている*1。それについて、ちょっと補足と実測値を。 まず、コメントにも書いたんだけど、サーバのスループットを測る際にはTCP接続を多重化する必要があるので、-a 100 -n 100 -f *2のようなオプションでベンチマークをとってください。あと、ローカルホスト上での測定か、ホスト間での測定か、によっても当然結果は変わる。 自分の環境 (linux 2.6.18-028sta

    HTTPプロトコルパーサのオーバーヘッドは18%以下という話 - kazuhoのメモ置き場
  • ウノウラボ Unoh Labs: PubSubHubbubとは

    yamaokaです。 Twitterのみならず、FriendFeedやFacebookなど よりリアルタイムに近い更新がwebで求められるようになってきています。 従来、更新情報の配信はRSSなどのフィードやAPIを通して行われてきました。 しかしその場合、配信している側のサーバーに 定期的にリクエストを投げないと更新があったかどうかわかりません。 サーバーへのアクセスが多くなった場合、結構な負荷になります。 さらにお行儀の悪いクライアントが存在すると、頻繁なアクセスを繰り返し、 あたかもDoS攻撃のような状況が起こることもありえます。 そこで考えられたオープンなHTTPベースのプロトコルがPubSubHubbubです。 Google ReaderとFriendFeedが対応している他、 日国内ではlivedoor Blogとliverdoor Readerがそれぞれ対応しています。 で

  • XMPPはクラウドサービスの将来像か?

    プッシュアーキテクチャ対プルアーキテクチャの議論が再び活発になってきている。この発端は、Jive Software(サイト・英語)のCTOであるMatt Tucker氏(source)が、次のように、XMPPのプッシュベースアプローチがクラウドサービスの将来像(source)であると宣言したことだ。 Webサービスアーキテクチャでは、新たな動きが起きています。クラウドサービスについて、現在は、これがWebアーキテクチャにおける基的な流れであり(source)、これにより、個別に分かれたサイロの結合から抜け出し、統合がより大きな効果を発揮するサービスのコラボレーティブネットワークへと移行できると盛んに言われています。問題は、現在のクラウドサービスを動かしているプロトコルです。SOAP、およびその他のさまざまなHTTPベースプロトコルは、すべて一方向の情報交換です。このため、クラウドサービス

    XMPPはクラウドサービスの将来像か?
  • 原稿・資料 ― ありえるえりあ

    アスキー NETWORK MAGAZINE原稿 アスキー NETWORK MAGAZINE 2005年3月号(http://nmag.jp/modules/xfsection/article.php?articleid=3)の「いま改めて知っておきたいこれからのP2P」の原稿です。 Read More…

  • 仙石浩明の日記: Perl の非同期I/Oモジュール POE を使って VPN-Warp relayagent を書いてみました

    多数の TCP/IP セッションを同時に維持する必要性などから、 非同期I/O が最近流行りのようです。 何をいまさら、という気もするのですが、 いわゆる「最新技術」の多くが 30年前の技術の焼き直しに過ぎない今日このごろなので、 非同期I/O 技術が「再発見」されるのも、 「歴史は繰り返す」の一環なのでしょう。 スレッドが当たり前の時代になってからコンピュータ技術を学んだ人にとっては、 (古めかしい) 非同期I/O が新鮮に映るのかも知れず、 なんだか「ファッションのリバイバル」に似ていますね。 Perl で非同期I/O 処理を手軽に行なうための枠組みとして、 POE: Perl Object Environment というものが あるようです。 POE を使うと、 あたかもスレッドを使っているような手軽さでプログラミングできます。 試しに VPN-Warp の relayagent を

  • WSDL:Webサービスのインターフェイス情報

    WSDLは何を記述している? あるアプリケーションがWebサービスとしてネットワーク上に公開されているとしよう。別のプログラムがそのWebサービスを利用するためには、次に挙げるWebサービスのインターフェイスに関する情報が必要になる。 ●そのWebサービスはどこにあるのか ●そのWebサービスは、どんなフォーマットのメッセージを使って利用するのか ●そのWebサービスは、どんな通信プロトコルを使ってメッセージをやり取りするのか Webサービスのインターフェイスを、人もプログラムも理解できるようにXML形式で記述するために開発された言語が、今回のテーマであるWSDL(Web Services Description Language)だ。CORBAのような分散オブジェクト技術では、インターフェイス記述言語としてIDL(Interface Description Language)が使用されて

    WSDL:Webサービスのインターフェイス情報
    starsky5
    starsky5 2009/02/05
    難しい...あとでじっくり読む。
  • http://code.sixapart.com/svn/memcached/trunk/server/doc/protocol.txt

    Protocol -------- Clients of memcached communicate with server through TCP connections. (A UDP interface is also available; details are below under "UDP protocol.") A given running memcached server listens on some (configurable) port; clients connect to that port, send commands to the server, read responses, and eventually close the connection. There is no need to send any command to end the sessi

  • 1