研究ぶーろぐ

パソコンにＶＭ入れて、Ubuntu入れてそこでOversimを動かしました。

なんだかわからんけど、楽しいうごきをしてくれます。
kdwkさんご指導ありがとござます！！

※調べて書きますいろいろと！

※書き足します

iKnowのブログパーツはこちらから。
サイトバナーもあって可愛いｖ

色も設定できます♪

完全受け売り！Firefoxのお勧めアドオン♪

来年はおにゅーパソコンを買う気がするので、
今使っているアドオンやよさげなアドオンをまとめました。

■Minibuffer
LDRizeやReblogCommandの基盤になっているScript
http://userscripts.org/scripts/show/11759

■GreaseMonkey
ユーザスクリプトを実現するための拡張機能・クライアントでカスタマイズする
http://www.greasespot.net/2007/05/greasemonkey-07-candidate.html

■AutoPagerize+LDRise（GreaseMonkeyスクリプト）
快適な組み合わせ！ページが超快適になる
http://userscripts.org/scripts/show/8551
http://userscripts.org/scripts/show/11562

■Nightly Tester Tools
対応していないアドオンを強引にインストールする
https://addons.mozilla.org/ja/firefox/addon/6543

■SwitchProxy Tool 改造版
Proxyの設定らくちん
http://firefoxhacks.at.webry.info/200802/article_1.html

■Foxmarks Bookmark Synchronizer
Bookmarkを連動してくれる
https://addons.mozilla.org/ja/firefox/addon/2410

■CustomizeGoogle
Googleをさらに使いやすくしてくれるツール
Google の検索結果に他の情報を追加し、スパムを取り除く
https://addons.mozilla.org/ja/firefox/addon/743

■Tab Mix Plus
タブ周りの機能を拡張し、タブブラウザとしての能力を向上させる
http://tmp.garyr.net/dev-builds/

■FireGestures
マウスジェスチャーで前後のページに飛ぶ。他多数ジェスチャー有。
https://addons.mozilla.org/ja/firefox/addon/6366

■Download Statusbar
ダウンロードの進捗状況をステータスバーに表示・操作
https://addons.mozilla.org/ja/firefox/addon/26


暇なときに、かきたしまーす*^_^*

かきます*^_^*

ちなみに、今よんでるMobile　P2PSIPにもPlanetLabを使用？してるみたいです＾

出典は、レポートに書いてない場合が多い。
書いてあるとしたら、レポート1枚目の一番下に書いてある（かも）

レポートの出典例
This paper appears in: Consumer Communications and Networking Conference, 2008. CCNC 2008. 5th IEEE


他に気づいたら書き足します*＾＿＾*

「Mobile P2PSIP Peer-to-Peer SIP Communication in Mobile Communities」

著者：Marcin Matuszewski, Esko Kokkonen
出展：IEEE Xplor**********


【アブストラクト】
本稿では、あらゆる種類の中央集中サーバをほとんど必要なしに、mobile community members 間で確立したSIP multimedia sessionsを可能にする、「マルチサービスP2P overlayアーキテクチャ」を実現させる提案をする。
オーバーレイアーキテクチャは、革新的なmobile servicesを提供するために、コスト効率的なプラットフォーム？(cost efficient platform)を形成している。
一例として、本稿ではmobile P2PSIP VoIPサービスの実現を提案します。
この提案は、携帯電話利用者はP2P overlayの資源を使って音声電話をする。
携帯電話利用者は、mobile pfoneのcontact listやstandard call managerを自由に使用してもよい。
本稿ではまた、NAT traversaを利用したNAT越えに用いるリレーサーバーの発見手法も提案する。


【提案手法】
・moblileにおけるP2P SIP VoIPサービスの提案
・上記の中における、NAT環境のrelayサーバの発見手法の提案

⇒NAT環境でのrelayサーバの発見手法を中心に読み進めます。以下、訳。

※GPRS　General Packet Radio Service
既存のGSM（Global System for Mobile Communications：ヨーロッパ発の第2世代ディジタル携帯電話方式）ネットワークにパケット交換網を付加し、高速なデータ伝送（最大171.2kbps）を行う通信システム。
※WLAN ワイヤレスLAN

１．イントロダクション

（途中略）

　多くのGPRSやWLANネットワークのほかに、現在、mobileエンドスポットのためにopening connectionsはNATやファイヤーウォールで制限されている。
（Besides many GPRS and WLAN networks today are behind NATs (Network Address Translators) or/and firewalls that restrict opening connections towards the mobile endpoints.）
少しのノード（それはインターネットに到達する）は、グローバル(public)IPアドレスを供給し、そして他のmobileエンドスポットから始まったコネクションを受信することを許されている。
確かに、P2P networkに加わる、また他のmobileエンドポイントとマルチメディアのセッションを確立する時、mobileエンドポイントの到達可能性を制限する。

以上の理由は、必要な従来の携帯電話のSIPエンドポイントとネットワークとの相互に作用する可能性がある分散型のcommunication mechanismの設計をする必要があり、ファイヤーウォールとNAT traversal問題の解決法を提供する。
P2P networkの上のVoIPコミュニケーションは、独自のシグナリングプロトコルでSkypeで最初に利用されました。
まもなく、Skypeは、internet communityでSIPリアルタイムcommunicationの分散型メカニズムの標準化の努力をされ始めた。
標準のP2PSIPプロトコルは、現在IETFのWGにより規定されている。


本稿は、マルチサービスmobile P2P overlayのアーキテクチャとlocating SIP proxyとSIPエンドポイントとP2Pオーバレイネットワークに繋がるメディアのような他のサーバをlokatingする作業を、分配するmobile P2PSIPシステムの実装を紹介する。
このアーキテクチャは、P2P content Sharing(共有)とリアルタイムSIP communication networkを組み合わせることができる。
本稿はまた、relay serversを用いたNAT traversalの方法を論じている。

２．アーキテクチャ

（途中略）

このアーキテクチャは２つ要素があります。
（１）Peers
P2Pプロトコルを操作しcontact情報のようなデータをソートすることにより、P2Pオーバレイネットワークを維持する。原則的にはそれらはアプリケーションを可能にしクライアントにオーバレイ内に貯蔵されたデータを挿入・回収・変更・消去することを可能にする。
（２）Clients
Peerに接続し、オーバレイネットワークに、あるいはから、情報を挿入あるいは回収する。
Peerとして作業することを望まない、あるいはできない装置はクライアントになりうる。
図１において、我々は２つのタイプのクライアントを提供している。
つまり、mobile phoneとNAT traversalにおけるやpeerとclientをassistするrelay serverである。


（途中、略）
オーバーレイはまた、STUNやTURNなどのサービスに関する情報を保存することができる。
サービスに関する情報は、service recordsに保存される。
STUN、又はTURNサーバーは、 P2Pのオーバーレイのcontact情報を公開することができる。
**************
それらのサーバからの援助を必要とするノードはP2Pオーバレイ内に位置し、直接それらに繋げられるだろう。
(Nodes that require assistance from those servers may locate them in the P2P overlay and connect to them directly.)


３．プロセス
※Publishの訳し方がわからない。良い言い回しないかな。

このセクションでは、先にのべたアーキテクチャを可能にするような３つの基本的プロセスについて述べる。
我々はこれらのプロセスを３つにわけた、すなわちrelay location prosidureとそれ自身のconectivity informatioの提案、およびセッションの確立である。
我々の提案において、想定することはいくつかのmobile endpointがNAT traversalの手順においてrelay serverのassistを必要とするかもしれないということである。
以下のセクションで３つの部門の分析を行う。

A,relay locationの手順
relayは例えばフィンランドにおけるrelayがフィンランドに位置する情報をpublishし、それがあるIPアドレスとポートに届くことが可能であるといったような、P2P overlayの情報におけるcontact informationをpublishする。
relayはstand aloneのnetwork entityかもしれないし、あるいはP2P overlay無いのpeersにより配置されるかもしれない。このシナリオにおいて我々が想定することはrelayはclient protocolを用いて、Peerと連絡しあう別のnetwork entityであるということだ。
このrelayの物理的位置が、relayに対するround trip time？のおおよその値を与えることになる。
メディアとまたはシグナルを出すrelayingを要求するNATの後ろ？にあるノードはrelay(TAN serverあるいは他のrelay)のアドレスを回収するために、P2P overlayを検索する（わからんので直訳です）
When～～～～（文型わからん文章）＊＊＊＊＊＊＊＊＊＊
（おそらくの訳）知られているrelayのaddresを回収するときは、relayにcontactしてpublicIPアドレスとport peerを必要とする。
そのrelayはノードに対するportを保存し、それ自身のIPアドレスとmobile endpointのreserved portに反応する。
従って、relayはこのIPとmobile endpointに割り当てられたportに送られたすべてのメッセージをmobilepointにおくる？？？（げせぬ）
relayは別のIPアドレスを備えsignalingやmedia trafficにportする。

B.他のnetwork nodesに対する自身のconectivity informationのpublication mobile endpointがpublic IPとport peerを獲得した後に、このデータはoverlayに対して、あるいはoverlayに抵抗してpublishされねばならない。
mobile endpointのconectivity informationは、endpointのuserに属するuser recordにためられる。
user recordはばらばらにされたuser IDを用いて、INDEXされる。
我々のimplemantation(実行・実装)においてuser IDはuserに割り当てられたSIP URIに等しいものである。
このpublicationはたとえそのdevidceがNAT以前のものだったとしても、他のNODEがoverlay無いのuserの現在のcontact informationを見つけることができ、userにcontactできることを保障するものである。


４．実装・実行
（３）relay server
リレーサーバは、NATあるいはファイヤーウォールtraversalに使われる。
mobile clientとrelayの間のプロトコルは、登録商標のプロトコルである。
それは、HTTPコネクトをrelayに対するTCPコネクションを作るために、あるいは、HTTP proxyなしにコネクションが可能であれば、直接的なTCPコネクションを作るために使用する。
このTCPコネクションはあらゆるファイヤーウォールやNATを迂回することにより、clientに対するfoward UDR(SIPあるいはUDPのパケット)に使用される。

このシステムにはいくつかの、relayがあるかもしれないし、Userは互いをconectするために同じものを使う必要はない。
relayはentity？（PeerとClient？）をわけることもできるし、統合することもできる。
※OPEX→operational expenses
2つ目の構想は、OPEX？を軽減することを可能にできるのでこちらのほうがよい。
このシナリオではPeerのNetwoｒｋはこうすることによりrelayとして作動するだろう。
実験において我々は、stand alone relay serverを用いたが、これはPlanetLabで我々が使用したPeersを変化させることができなかったからである。

また、relayを必要としないシナリオも多くある。
本当の配置においては、標準的なNAT traversal メカニズム・ICEやSTUNはまたNAT　traversalにおけるノードをassistするために使われる。
我々がrelay serverを使うのは、P2P overlayがNAT　traversal内のclientやpeerをassistできるようなrelay serverを定めることもできるからである。

次のセクションで述べることはセクション３で記述した基本的プロセスを実現するのに用いるmassege flowを述べている。

前回に読んだ
「A Hierarchical Peer-to-Peer SIP System for Heterogenerous Overlays Interwoeking」
で、ミーティングで聞かれた内容を書いておきたいと思います。
（質問の内容は慌てて書きとめたので、内容がおかしい点もあるかと思います！ごめんなさい！）


■ SIPの INVITE と NOTIFY これをルーティングするのはどれくらい大変か？
・INVITE メソッドによる、セッションの確立。
・SUBSCRIBE / NOTIFY メソッドによる、プレゼンス通知。

■ フラットアプローチのメッセージが沢山流れてしまう解決法とされているHierarchicalアプローチでは、階層ができるため余計に多くのメッセージを流してしまうのではないか？


【以下、他に調べたことを書き留めておきたいと思います】

・