exB - extreme B-AREA -

多くの常連が無駄死にで無かったことの証の為に・・・ 再び一陣の先頭を守る為に! 正門よ!私は帰ってきた!!

SlavaNap - ギガ男爵のお勉強タイム:番外編

あなたもいっしょにうたたねしませんか。

B地区鯖のご案内~SlavaNap鯖~

「アップダウン号はすぐに流れるので嫌だ!」

ふざけんな何のリスクもないのに文句いうんじゃねえ、というのがホンネですが、鯖立てしみました。もっとも、こんなご時勢だと落すほうもリスクあるんだからね!

  • 非公開鯖です。
  • 登録制です。
  • 一見さんお断りです。
  • 中に入ると天国です。これでもう取り逃しの心配はありません。
  • でも落とし放題というわけではありません。OCN なので(refer)。
  • 今は JCOM になったので Nap 系通信はがっつり遮断されてます。ま、CATV はどのみち上りが絶望的に遅いので鯖向きではないのですが。
  • 爵位が必要です。奴隷に権利などありません。

そんなわけで、アップダウン号よりもはるかに敷居は高くなってしまった!当然だよ!なんのこったかわからない人を受け入れる気はないし。管理側から見れば、どういう制限がかけられるのか一目瞭然なので面白いですねえ。なお JCO Mは IP 半固定なのですが、お約束の DiCE + ダイナミック DNS による FQDN でのアクセスとさせていただいております。

そもそも、気が向いたときしか立ち上げてないよ!

JCOM 解約後、アクセスラインが WiMAX だったので長いこと子鯖もうたたねも稼働を見合わせていましたが、光回線復活につき“ fx.b-area.org:**** ”で試験運用中です(規制は掛かってない様子)。

B地区鯖のご案内~HTTP鯖~

HFS 使ってます。FTP 鯖立てるよりもお手軽で便利ですねえ。

HFS HTTP File Server 日本語化 (v 2.3)

普段使いのマシンを鯖に見立てるのはいろいろリスク高いので常時開設というわけではありません。SlavaNap で速度が出なかったり規制掛かってるひと向けに、発生ベースで起動しています。

OpenNap / SlavaNap について

全盛期から10年以上経過して知らない人も増えたので、補足してみる。

あらまし

OpenNap は今世紀初頭を席巻した WinMX のプロトコル、WPNP( WinMX Peer Networking Protocol )の亜種。WinMX 自身 Napster 社のファイル共有サービスに接続するための互換ソフトで、Napster のほかやはり互換性のある草の根サーバーに接続することで巨大な P2P ネットワークを構築していた。Napster 社が RIAA の提訴によりサービスを中止してからもこの草の根サーバを中心とするネットワークはハッカーの手によってさらなる改良が施され、OpenNap として定着した(本来プロトコルを指す言葉だがサーバを指すこともある)。なお OpenNap 系のサーバは検索にハッシュテーブルを利用するため日本語の検索精度に難があり、国内では独自に strstr 関数を採用した SlavaNap が広く浸透、FaceNap など SlavaNap 互換のサーバソフトも作られた。接続ソフトには WimMX 以外に様々なものが存在するが、日本ではうたたねが普及している。

OpenNap や SlavaNap においてサーバはネットワークに接続するノードの情報を集約しデータベースを構築、接続するノードに他の参加ノードの情報を提供する役割を持つ。各々のノードはこの情報をもとに必要に応じ他のノードと通信を行う。このようにクライアント/サーバでノード情報を取得し実データのやりとりはピアどうしで行う、いわゆるハイブリッド型ネットワークである。

ハイブリッド型は接続ノードの情報を一元管理しているためWinnyのように集権サーバを持たないピュア P2P に比べて手早く目的のピアを探すことができる反面、サーバを喪失すると一気にネットワークがダウンするのが弱点(成立している通信は維持される)。またサーバに接続できなければネットワークへの参加は不可能で、主にやりとりされるファイルの関係上サーバの運用にもリスクがつきまとうためおのずと閉鎖的になりやすい。

OpenNap / SlavaNap ネットワークの構築

新たに OpenNap / SlavaNap ネットワークを立ち上げるハードルは高い。

ネットワークの知識
サーバ、クライアント問わず最低でも TCP/IP の基礎くらい身に付けてないとルータのポートフォワード設定ダイナミック DNS の運用に苦労する。
広帯域かつ干渉のない回線の確保
規模にもよるが、ピアは大容量のデータをやりとりすることが多く、サーバは多数のコネクションを維持する必要がある。また P2P 規制を実施しているプロバイダが多く、要件を満たす実用的なプロバイダは少ない。
なお理想は固定IPアドレスだが、DHCP 環境下でもダイナミック DNS を利用すれば FQDN によるアクセスが可能。
サーバ
日本語処理に優れた SlavaNap 系の Facenap が初心者でも扱いやすい。Windows 上で動作するので UNIX の操作スキルも不要。
サーバを動かすマシンのスペックは1000単位のノードでもない限りごく普通のパソコンで問題ない。ただサーバはその性質上連続稼働が求められるので、普段使いと同じマシンで運用するのは何かと不便を強いられる可能性がある(たまにメンテナンスが入るのはともかく日常的な利用制限は参加者から敬遠される)。
クライアント
国産のうたたねが無難。というか他に知らない( 32bit アプリケーションだが 64bit OS でも問題なく動作する)。マシンのスペックは問わないが、ストレージに余裕がないと厳しい。なおシェア≒参照できるのはフルパスがアスキー換算 255 バイトまでのファイルに限られるようだ( Facenap はデフォルトのファイルインデックスのパス長が 128 なので、共有が見えない問題はサーバ側の制約もあるかも)。
なお共有するファイルの視認性には気を遣うこと。入手したファイルそのままでリネームされていないような参加者は敬遠されるし、早めに手を付けないと自分でも把握するのが困難になる。
参加ノードの確保
これがいちばん難しい。公開鯖にすると確かに頭数は集めやすいがいろんな意味で質を保証できないしリスクも高まる。基本は非公開鯖で、時間は掛かっても他の子鯖の参加者から質の高い共有、かつ信頼できそうな人を地道にスカウトするのが無難。

道のりは遠いが熟成に至った非公開鯖は互いのバックアップをみなで持ち合ってるようなもんで、HDD がクラッシュしようがどうにでもなる。機会があればまたやってみたいもの。

参考:Facenap7.7.29.741 / うたたね1.043

いつ消えるかわからないので B地区鯖にあげとく。いずれも 32 ビットアプリケーションだが 64 ビット環境でも動作する。なお“うたた寝”は英語で“ Nap ”。

補記~通信速度と安定性に関して~

いろいろ誤解が散見されたので軽くおべんきょうです(ぜひ理解してほしいのでここは「ですます」調で)。

有線 LAN の主流規格であるイーサネットは 8b/10b エンコーディングを採用しているため、通信に占める実データの比率は 8 割で残りはクロック信号によるオーバーヘッドとなります。早い話が“規格上の理論値の 8 割が実効スループットの上限”となります。たとえば IEEE802.3u ~いわゆる Fast Ethernet ~の 100Mbps であればアプリケーションレベルで実効 10MB/s 以上出ることは“あり得ません”。さらに実際の通信ではパケットヘッダや 3WAY Handshake などによるロスも発生するため研究室などの特殊な条件下であっても理論値の 100% にはなりません(たまに P2P とかで「 12MB/s 出た!」とか騒いでる人いますが単なる測定ミスです)。

また外部の干渉を受けやすい Wi-Fi 等の無線 LAN では有線 LAN 以上にこうしたロスが激しくなります(干渉の一切ない電波暗室であっても理論値通りの速度が出ることはありません)。さらに暗号化方式によっても処理負荷が増減しますし距離による減衰もありますから、「無線はカタログスペックの半分出れば御の字」というのがネットワークエンジニアにとっての常識です。

特に現在の Wi-Fi の主流 IEEE802.11b/g/n が用いる 2.4GHz 帯で無線通信に割り当てられている周波数帯は 80MHz しかなく、1 つの通信チャネルで 20MHz のバンド幅を利用するため同時に使用できるのは実質 3 回線どまりです。また 2.4GHz は障害物の影響が少ないため通信可能な距離を稼ぐことはできますが、裏を返せば外部からの電波干渉を受けやすいということにもなるのです。このことは通信の安定性において大きな不利となります。

2.4GHz 帯でよく言われる電子レンジの影響は気にしなくてもいいでしょう。1日中電子レンジ使ってるなんてコンビニくらいのもので、単純にほとんどの家庭・職場の無線 LAN 機器が 2.4GHz を使ってるのが問題なのです(アパートやマンションで SSID を拾うとものすごい数がヒットしませんか?)。

安定した無線 LAN 環境を実現するにはバンド幅が広くかつ干渉を受けにくい 5GHz 帯を使用する IEEE802.11a/n/ac を導入すべきです(もっとも、安定性最重視であれば有線 LAN にするのがいちばんですが)。スマホやタブレット、ルータなど Wi-Fi を利用する製品をチョイスする際は a/n/ac 対応の有無をしっかり確認しておいたほうがよいでしょう(以前に比べると普及が進んだとはいえ低価格帯では未だにサポートをおろそかにしてるメーカーが多いです)。ちなみに 5GHz の通信は電波法で屋外での利用が禁じられていますので、モバイルルータなどでは無効にしておく必要があります。

イーサネットに限らず USB 3.0PCI Express なども含め、シリアル転送はその性質上クロック信号をパケットに埋め込む必要がありオーバーヘッドをゼロにはできませんが、損失が 2 割ってのはあまりにもアホくさい、ということで PCI Express 3.0 では効率のよい 128b/130b エンコーディング( 損失 1.5% )が採用されています。8b/10b では 「128bitのデータ( 16 バイト)」をやりとりするのに物理層を流れる通信量は 160bit 必要だったのが、128b/130b では文字通り 130bit で済むようになったわけです。

シリアル転送がコーディングを行う理由はほかにもあるのですが( ex. コーディングでエラーをなくせ!|Panasonic )、ひとまずオーバーヘッドが存在することだけ知っておけばよいと思います。

ちょっと脱線しましたが、一般的な有線 LAN でアプリケーションがやりとりするデータの実効スループットはネットワーク上を流れるデータの 8割が上限ということ(現在のコンピュータは 1 byte = 8 bit なので bps を 10 で割ればおk~ ex. 500Mbps → 実効 50MB/s )、無線 LAN は障害物の影響が少ない 2.4GHz 帯より 5GHz 帯のほうが外部干渉を受けにくくバンド幅も広いため通信の安定性が高いことは、知っておいて損はないでしょう。

脚注

ノード
種類や機能、役割を問わずネットワークに接続されている機器を意味する言葉。ハブのようにアドレスを持たないものは含まれないことに注意(ここでいうアドレスは主としてネットワーク層のものだが、稀にデータリンク層を含む場合もあるので文脈で判断する必要がある)。
なおノードが意味するのは単にネットワークの参加者で、 ピア は端末がサーバとクライアントそれぞれの機能や役割を持つ場合に用いる。
TCP/IP
Transmission Control Protocol/Internet Protocol。 通信手順のひな型であるOSI 参照モデルの第四層( トランスポート層 )と第三層( ネットワーク層 )に相当する、インターネット標準プロトコル。このうち IPは ネットワークにおける場所 、 TCP(及び UDP )は ノードにおける用途 を定めるもので、それぞれ IP アドレス ポート番号 を提供する。事実上の世界スタンダードで採用していないネットワークを探すほうが難しいほどだが、インターネットが普及する前は様々な(中間層の)プロトコルが存在し、 Windows 3.1 も標準でサポートするのは NetBEUI のみで TCP/IP (≒インターネット)を利用するには別途 LAN Manager などを組み込む必要があった。
なお TCP/IP をはじめとするインターネット関連技術は IETF によって標準化が行われ RFC として公開されている。 OpenNap は HTTP や FTP などと同様に TCP/IP の上位層である アプリケーション層 に属するが、 IETF の関与しない野良プロトコルである。
IP は アドレス空間が 32 ビットの version 4128 ビットの version 6 が利用されている。まず v4 が普及したが割り当て可能なアドレスは約 40 億と世界人口よりも少なく、早くからその枯渇が懸念されていた( 2011年 4月、日本での IP アドレスの割り当てを管理している JPNIC から v4 アドレスプールの在庫が切れたことが発表されている)。 v6 は 40億 x 40億 x 40億 x 40億という枯渇とは無縁の広大な空間を持ち、また設計段階からアドレスの自動設定や拡張性が想定されているため v4 よりもずっと高機能だが v4 との互換性がなく、表記もかなり異なる。すでにバックボーンではほとんどのハードウェアやソフトウェアが IPv6 をサポートしデュアルスタックやトンネリングなどによる相互運用も広まっているが、 v4 前提で動作するソフトウェアやネットワーク機器もまだまだ数多く、 IANA による IPv6 アドレスの割り充てが開始されてから 20 年近く経った現在でも完全移行のメドは立っていない。

すべての端末に v6 を義務付け、 10 年くらいの準備期間を置いたのち gTLD や ccTLD が v4 のサポートを停止くらいのことをやらないと無理だろうね。

枯渇する以前より限られた IP アドレスを拡張する苦肉の策として、アドレス変換技術のひとつである IP マスカレード を導入する上位ネットワークも多い( NAT とも呼ばれるが実際にはポート番号も変換する Network Address Port Translation の NAPT であることがほとんど)。この場合ネットワーク層レベルでのエンドツーエンド接続が保証されないので、アプリケーションによっては通信に制約が生じることもある※。ルータ経由でインターネットに接続しているノードのほとんどがこれに相当するほか、直接接続でもケーブルテレビ系プロバイダや WiMAX などは IP マスカレードによるプロバイダの プライベートネットワーク のアドレスを提供している。
※ OpenNapやうたたねを含め、アプリケーション層で動作するプログラムやプロトコルはほぼこれに該当するため、エンドツーエンドの保証にトランスポート層、すなわちポート番号を必要とする。
FQDN
Fully Qualified Domain Name、完全修飾ドメイン名。インターネット上の端末の名前(ホスト名)を一切省略せずに表したもの。 FQDNを DNS サーバ に問い合わせることでその端末の IP アドレスを得ることができる(これを 名前解決 と呼ぶ)。
一般にインターネットの利用者は専用の IP アドレス(固定 IP )を持たないことがほとんどで、接続ごとに IP アドレスの異なる DHCP による割り当てとなっている場合が多い。DHCP による割り当てでは IP アドレスで永続的に端末を特定するのが困難だが、DNS サーバが保持しているホストのアドレスを動的に書き換えるダイナミック DNS を利用することで FQDN による名前解決が可能になる。

…新たに OpenNap ネットワークを立ち上げるなら最低限この程度の知識はほしいところ(ピュア。