TidBITS: Apple News for the Rest of Us  TidBITS#601/15-Oct-01

Mac OS X 10.1 は成功であったが完全無欠というわけではない。そこで今週はMatt Neuburg が 10.1 のインターフェースは統一性に欠きかつ理解に苦しむと言う一つの例について検証する:「開く」と「保存」ダイアログである。ネットワーク賢者に対しては Adam が、インターネット接続をモニタしかつその接続性を向上させる驚きのネットワークデバイス PacketShaper について語る。ニュースの部では次の記事を扱う;4D 社 WebSTAR V を出荷、MacworldがIDG のもとに戻り、そして Handspring 社が携帯電話と PDA のハイブリッドTreo Communicator を発表。

記事:

Copyright 2005 TidBITS: Reuse governed by Creative Commons license
<http://www.tidbits.com/terms/> Contact: editors@tidbits.com>


本号の TidBITS のスポンサーは:


MailBITS/15-Oct-01

Handspring 社 Treo Communicator を発表 -- Handspring は本日 Treo Communicator を発表した。これは、Palm OS ハンドヘルド、携帯電話、それにページャー(ポケベル)を一緒にした一体型機器である - ただし近々の内に一台と言うわけにはいかない。Treo 180 は Palm プラットフォームとしては初めて、初代の Pilot 以来 Palm 機器の定番となってきたスタイラスベースの Graffiti 文字認識システムの代りに、BlackBerry 型ミニキーボードを搭載している。それでも Graffiti の方がいいと言う向きには Graffiti を使った Treo 180g モデルを注文できる。どちらのモデルも電話サービス加入申込み後で $400 であり、16 MB のメモリ、高解像度グレースケールスクリーン、充電型電池が付属し、Palm OS で動作する。Treo には、Visor のSpringboard 拡張スロットが付いていない。これは、Treo は専用のオーガナイザと言うよりは、筋力増強剤で強化した携帯電話という趣の方が強いからであろう。今日の発表で同じ様に興味を引いたのは、Treo が実際にユーザの手に渡るまでの長いリードタイムである:Handspring によれば、入手できるのは Treo 180 及び 180g 共に 2002 年の早い時期、カラー版で $600 の Treo 270 は 2002 年の半ばになると言う。ハンドヘルド市場の急激な落込みとHandspring 社の株価の下落(現在は $3 前後で取引されているが、数ヶ月前は $1.13 までいった)を考えれば、 たとえ製品自体は四半期かそれ以上も先でないと出ないとしても、この発表で自社に対する信頼度を強化したいとの狙いがあるものと推測する。Handspring の発表は、ライバルである Palm, Inc.から出されるであろうと噂されているワイヤレス機器に対する先手を狙った攻撃と見ることも出来るかもしれない。[JLC](カメ)

<http://www.handspring.com/products/communicators/>
<http://www.rim.com/products/handhelds/>

Macworld が IDG へ復帰 -- 4 年前、Macintosh 業界がちょっと落ち込んでいた頃、Macworld と MacUser という 2 つの一流 Macintosh 雑誌の激しい宣伝合戦に終止符が打たれた。それは International Data Group(IDG)社と Ziff Davis 社が 2 誌を(Ziff Davis の MacWEEK 誌と共に)、Mac Publishing 社というジョイントベンチャーに併合したからだった。併合された直後に MacUser は Macworld に吸収された。またMacWEEK は eMediaweekly という週刊誌や、Mac Publishing のウェブ版日刊ニュースサイトといった形で生き残る努力をしたが、最後にはMac Publishing が 1999 年に買収した MacCentral ニュースサイトに併合された。さて先日、IDG はジョイントベンチャーに関する Ziff Davis の持ち分を買い取り、Mac Publishing を 100 % 所有の子会社にした。IDG に戻った米国 Macworld 誌は、Macworld Conference & Expo および10 誌の他国版 Macworld と再統合された。ところで、この変化は Mac Publishing と Macintosh 業界の両方にとって好ましいものだ。なぜならMac Publishing は奇怪な会社組織に合わせて作られたジョイントベンチャーだったのに加えて、IDG と Ziff Davis の競争によって社内的な混乱がさらにひどくなっていたからである。[ACE](吉田)

<http://maccentral.macworld.com/news/0110/10.macworld.php>
<http://db.tidbits.com/getbits.acgi?tbser=1208>

WebSTAR V の Mac OS X 版が出荷 -- 4D, Inc. は WebSTAR Server Suite V for Mac OS X の出荷を始めた。これは、昔からあるもう一つのMac OS 用インターネットサーバが Apple 社の新しいオペレーティングシステムへ(そこに Unix ベースのインターネットサーバ群が組み込まれているにもかかわらず)移行したことを示している。WebSTAR V は今やMac OS X と Mac OS X Server のネイティブアプリケーションとなり、マルチプロセッサ対応とキャッシュ方式の改良によって Apache を凌ぐ性能をうたっている。さらに4D は使いやすさを重視している点でもApache と異なっている。仮想ホストの管理権限を個別に委譲できたり、すべての管理をリモートで行えたりするのだ。他には次のような新機能や改良点がある。非常に速くなった検索エンジン、WebDAV によるファイル共有サービスの内蔵、Unix と Perl による CGI のサポート、SSL 対応を含む強化されたセキュリティオプション、WebSTAR Admin による人手を要さないサーバの監視と再起動、そして複数の IP アドレスで接続を待てる FTP サーバである。WebSTAR V は Mac OS X 10.0.3 以降と128 MB の RAM、50 MB の空きディスク領域を必要とする。WebSTAR 3.xからのアップグレードは 300 ドルで、WebSTART 4.x からの場合は 200 ドル。新たに買うと 400 ドル(600 ドルから値下げされた)であり、サポートとアップデートを一年間受けられる。その後もサポートとアップデートを受けるには更新費用として年額 180 ドルを要するものの、更新しなくても動作には支障はない(アップデートは受けられないが)。無料のデモ版が入手可能 [ACE](吉田)

<http://www.webstar.com/>


Appleの隠れた汚点

文: Matt Neuburg <matt@tidbits.com>
訳: 倉石毅雄 <takeo.kuraishi@attglobal.net>

埃が落ち着き、Mac OS X 10.1でAppleの新しいOSが卵から幼児へと成長した。皆それぞれ好みの機能がある:メニューやダイアログをコントロールするキーボードショートカット、Finderでコピーとペースト(そして取り消し!)を使ってのファイル操作、AppleScriptの市民権の復権など。しかし、Mac OS X の 最悪な点はどれだ?答えなくても良い。私がこれから教えてあげよう。それはファイルの名前の終わりをごちゃごちゃにしているファイル拡張子ではない。(トップを争っているのは事実だが。)あなたの大好きな周辺機器のサポートの欠如でもない。私にとって、それは「開く」と「保存」のダイアログボックスだ。

System 6以来、私はAppleの「開く」と「保存」のダイアログボックスに憤っている。その理由は、私の母のマックの使用方法を見てみれば分かるだろう。このコンピューターの標準的な環境はファイルシステムをナビゲートするのに素晴らしく使いやすい方法だ(「Finder」と呼ばれているが、母は余りよく認識していない)。彼女はこの使用方法にかなり慣れていて、上手である。しかし彼女がファイルを開けたり保存したりしようとすると、全く異なる方法を使い、しかも面倒な手順に束縛されることになる。今どこにいるか、もしくは保存した居場所に移動するにはどうすれば良いか分からない。Finderでは明らかな「コンピュータ上の場所」を意味する視覚的ヒントや、使い慣れた移動用の近道や標準的な手順が見当たらなくなってしまう。

開発者らがこの点について過去十年以上、World-Wide Developer Conferenceでのtalk-backセッションの度にAppleに文句を言っている。AppleはMac OS Xでこの昔からの問題を根本から取り除いて一からやり直す機会があった。しかし彼らはこの好機を完全と言って良いほど逃した。

「完全と言って良いほど」と言ったのは、改善点がいくつかはあるからだ。新しい「開く」と「保存」のダイアログボックスは複数の列を表示し、ファイル階層中で自分がどこにいるかがわかりやすくなった。頻繁に使う項目や「お気に入り」フォルダーなどのメニューインタフェースはMac OS 9のNavigation Servicesに比べてはるかに良いので、活用することも多くなるだろう。最近使ったフォルダーも含まれる。Navigation Servicesで紹介された機能も引き継がれている。(伸縮ハンドルが表示されないのでMac OS Xでは気が付かないかも知れないが、)ダイアログは伸縮可能だ。もしうまい具合にウィンドウを配置出来れば、ファイルやフォルダーを「開く」と「保存」のダイアログにドロップしてそこへ移動することも出来る。これを使えば、ダイアログのすぐ後ろのFinderで行く先のファイルやフォルダーが見えているのにダイアログ中ではややこしい移動操作でしかそこに至れないという状況を避けることが出来るだろう。

Finderもどき? -- しかしなぜ「開く」と「保存」のダイアログボックスがMac OS XのFinderと同じように働かないのだという疑問は残る。(なぜ「開く」と「保存」のダイアログが必要かという大きな質問は置いておこう。ファイルを開いたり保存したかったらFinder中に行けるべきだと昔から思っている。それは欲張りすぎか?)

Finderではいくつかの表示方法がある:アイコン、リスト、列など。「開く」と「保存」のダイアログでは列の表示方法しかない。なぜだ?その表示方法が好きでなければどうする?リスト表示で何が悪い?二つ以上の列ではないが、いくつかの利点がある:特にファイルの名前以外の基準で並べる場合など。なぜ「開く」と「保存」のダイアログではそれをやらせてくれないんだ?

さらに、「開く」と「保存」のダイアログの列表示は本当の列表示ではない。安っぽくって統一性がない、Finderの偽者でしかない。見た目の列表示との類似と、細かいところでの違いのために、混乱を招く。例えば、Finderの列表示では手動で列幅を調整できて、長いファイルの名前を完全に見られるようにすることが出来るが、「開く」と「保存」のダイアログでは出来ない。FinderでOptionキーを押すことにより、省略された長いファイルの名前を即座に見ることが出来るが、「開く」と「保存」のダイアログではそうはいかない(カーソルを名前の上へ持って行き、ツールのヒントが現れる気になるまで、気長に待たなくてはいけない)。

<http://db.tidbits.com/getbits.acgi?tbart=06584>

さらに困ったことに、キーボードでの移動が同じようには働かない。Finderのウィンドウ間で移動するために覚えた動作を使うと、「開く」と「保存」のダイアログではおかしくなることもある。FinderではTabとShift-Tabで階層を上下できるが、「開く」と「保存」のダイアログではファイル間移動から完全に飛び出てしまう。Finderでは左右の矢印で階層を上下し、上下の矢印で今いる階層中を移動できる(文字をタイプすればその文字で始まる最初のファイルの名前へジャンプする)。しかし、「開く」と「保存」のダイアログではこの動作に統一性がない。右の矢印は時々働いたり、何もしなかったり。下がって行きたい階層が見えているにも関わらず、キーボードを使ってそこにたどり着けない。時には左矢印は何もしないが、時には働く。上の階層へ移動するが、ファイルを含むフォルダーではなく同じレベルにあるうちのアルファベット順で最初のフォルダを選択する(左の矢印を押して、上矢印を何度も押したのと同じような動作だ)。さらに混乱に拍車をかけたければ、Carbonアプリケーション中で何度も上や下矢印を押してみればいい。

キーを打つもの似たようなものだ。一文字タイプしたら、ファイル階層中で目的地とは何ら関係のない見覚えのない場所に移動している。時には一文字タイプしたらダイアログのファイル移動領域が真っ白になってしまう!

この気違いじみた状況を体験してみたかったらCarbonアプリケーションが必要だ。この一因はCarbonとCocoaがこの点に関して全く違う働き方をすることにある。例えばSherlockを見てみよう。Sherlock中でファイル→「検索条件を開く」を選択し、「開く」シートでMac OS Xのハードドライブの最上階まで移動する。矢印キーだけを使用して/Library/Scripts/URLsまで下がっていく。ここまでは良いが、ここで行き止まりになってしまう。右矢印ではURLフォルダに行けない。下矢印を押してみよう。何が起こるか見当がついた?どこにいるか分かる?上矢印を押して元へ戻ってみよう。完全に混乱しているはずだ。ダイアログの移動領域は空白かもしれないし、シートの左端の画像が少々おかしくなっているかもしれない。このキーボードでの移動のルールはなんとなく分かる気もする。だがそれを分かっていても、FinderやCocoaの「開く」と「保存」のダイアログとの統一性が所々で欠けているし、ルールに従うのも非常にややこしいから、大して助けにならない。

これは許容しがたい状況だ。TidBITSの600号に相当する、余りにも長い間、私たちユーザはFinderと「開く」と「保存」のダイアログでのファイル階層を移動する方法が異なるという馬鹿げた二分性にさらされてきた。黙ってこれを受け入れるべきではない!「開く」と「保存」のダイアログの使いづらさを体験したら、肩をすくめてその状況を許容するべきではない。Appleを設計室に引きずり戻して、不要な非統一性を直せと言うだけでなく、全部直させよう!「開く」と「保存」のダイアログはFinderと全く同じように働くべきだ!今こそ机を叩こう。下のURLを使えばよい。

<http://www.apple.com/macosx/feedback/>


インターネットのトラフィックに手を入れる

文: Adam C. Engst <ace@tidbits.com>
訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>
訳: 佐藤浩一 <koichis@anet.ne.jp>

今年の4月の事件を覚えていらっしゃる方もあるかとは思うが、あの時はGeoff のマシンへのブロードバンド接続が突然に跡絶えてしまったため、数多くある TidBITS サーバーを、彼のマシンから当時シアトルにあった私の自宅内のマシンへ、か弱い 56 Kbps のフレームリレー接続に頼るものへと移さねばならなかった。少しでも高速のアクセスを確保するために、digital.forestにある我々のメインのウェブサーバーに記事をキャッシュするなど出来るだけのことはしたのだが、それでも TidBITS のサービスのうちのいくらかはその後一ヵ月ほどの間、わが家へのか細い回線を通る膨大なトラフィックのためにかなりの影響を受けざるを得なかった。

接続の断絶という危機に Geoff がどう対処したのかは、TidBITS-588 の記事“Surviving Your ISP's Darkest Hour”を読んでもらいたいのだが、私のマシンの方で一ヵ月もの間この危機に対処できたのは、実は PacketShaper というもののおかげだった。Packeteer 社の製品であるこの PacketShaper は、本当に魔法のようなネットワークデバイスと言っても過言ではない。普通の人が気軽に使うには値段が高すぎるが、インターネットでのパフォーマンスを監視して保持したいという切実な必要に迫られている人にとっては、PacketShaper は驚異の救世主なのだ。

<http://db.tidbits.com/getbits.acgi?tbart=06494>
<http://www.packeteer.com/products/packetshaper/>

Adam はネットワークの初心者 -- 話の発端は Geoff のブロードバンド接続が断絶するよりも以前に遡る。私のインターネット接続が突然、泥沼に足を突っ込んだかのように遅くなることがあったのだ。技術的情報を言えば、ping テスト、すなわちインターネット上の1つのコンピュータに向けて1個のパケットを送って、返ってくるまでの時間を測定するテストをしてみると、通常は 100 ミリ秒ほどであるはずのものが 3,000 から 5,000 ミリ秒もかかったりした。体感速度もはっきり違っていた。ウェブページのロードが信じられないほど遅くなり、他のインターネットサービスも反応の手応えがいつもと違っていた。さっきも言ったとおり、まさに泥沼を歩く感じだった。

この問題はごくたまにしか起こらなかったので、テストは困難だった。数か月にわたる観察の結果、なんとかデータを記録することができて、私の ISP に依頼してネットワークへのアタックを受けているのではないことだけは確認してもらえた。それ以外に私の思いついた可能性は電話回線のハードウェアの問題、ということだけだったので、私は次に Qwest に問い合わせてみた。Qwest の技術者が回線を調べてくれた(幸いにもちょうど問題が発生している時にこの技術者と連絡がついたのだ)が、速度低下は私の接続のうち外向きの通信についてのみ起こる、ということが判明した。これで私は、はたと気が付いた: これは、ネットワークの問題ではなかったのだ - 原因は、LetterRip Pro を走らせている私の SE/30 だった! TidBITS の翻訳版が各国の翻訳チームの手によって完成されて私のところに届く度に、LetterRip Pro は即座にこの 30K ほどのファイルをメールにして 700 から 1,300 ほどずつの宛先に向けて発送するのだ。これは非常に大量のデータなので、いくら SE/30 が今日のマシンに比べて(悲しくも)パワーが劣るとは言っても、この 56 Kbps のインターネット接続を溢れさせるには充分以上のものだったのだ。

私は、LetterRip Pro の設定を調整して、同時に接続できる外向き接続の数を制限し、この問題を緩和することができた。しかしまだ私には納得がいかなかった - 私のこのささやかな SE/30 1台だけでこんなにも簡単にインターネット接続を溢れさせることができるなんて、どうしても正しいこととは思えなかったのだ。もっとエレガントな解決法がきっとあるに違いない、と考えているうちに、私はまさに最適任の友人がいることを思いついた。彼の名は Richard Ford、熱狂的なネットワークの信奉者で、Apple 社の Open Transport プロダクトマネージャの職を経て Packeteer に移った人物だ。実際、私が問題点を説明すると、Richard は即座に PacketShaper を使うことを提案してくれた。この機械を使って状況を観察し、トラフィックを「調整」して問題を解消してみたら、というのだ。そう言えば Hotline ユーザーが 256 Kbps の ISDN 接続を溢れさせるのを防ぐ、という実演を Richard が MacHack でやってみせた時に、あの紫色のピザボックス型をした PacketShaper 機器を私は1度見た覚えがあった。というわけで私は乗り気になり、やってみることにした。

<http://db.tidbits.com/getbits.acgi?tbart=05470>(日本語)The Mac Hack Contest 1999

PacketShaper が救援に駆けつける -- PacketShaper をインストールするには私のネットワークを構成し直さなければならなかった。PacketShaper は私のルータとネットワークのそれ以外の部分との間に位置している必要があるからだ。そうすることで、すべてのトラフィックが PacketShaper を通過して行くことになり、この機器の魔術が可能になるのだ。インストールが終わると、ウェブブラウザを起動させてこのデバイスのウェブベースのインターフェイスにアクセスする。デバイスへのログインは巧みなリバース・ルックアップ機構によるもので、新しい PacketShaper 機器に IP 番号が割り当てられるよりも前にも接続が可能になるのだ。いくつかの設定を済ませれば、もうこれで PacketShaper が使えるようになる。

私たちが最初にチェックしたのはネットワーク効率のグラフで、その結果私のネットワークでのインターネットトラフィックの効率は何と 65% から 75% という低いものであることがわかった。これはひどい。つまりこれは、3・4回のパケットのうちの1回はどこかで消えてしまって再送信を必要とし、その結果接続効率が低下している、ということなのだ。私の場合、原因はコンピュータのオペレーティングシステムが高速のイーサネット・ローカルエリア・ネットワーク (LAN) のために最適化されていて、私のような低速の 56 Kbps のインターネット接続と噛み合うようには出来ていない、ということだった。このような LAN とインターネットとの間の不整合は高速のインターネット接続の場合にもよく起こることなので、Packeteer はこれに対処するために“rate control”という PacketShaper のためのテクノロジーを開発した。PacketShaper はインターネットに出入りするすべてのパケットを見たり触れたりすることができるので、この“rate control”設定によって接続を調整してパケットが失われる頻度を減らせるというわけだ。

「情報スーパーハイウェイ」の例え話を普段から聞き飽きている皆さんにまたここでそういう話をしてしまうのは申し訳ないのだが、インターネットを高速道路に、インターネットと個々の LAN との間の接続を高速道路のインターチェンジに、それぞれ例えるとすれば、PacketShaper の“rate control”機能はちょうどあの交通抑制信号灯が高速道路に進入する自動車の数を数秒に1台だけに制限して、各自が勝手に好きな速度で進入できないようにしているようなものだ。この信号灯によって高速道路に進入する個々の自動車の速度はちょっと抑えられるが、結局は交通がよりスムーズに流れるようになり、高速道路の全体としての能率が向上する。同じことがネットワークの世界でも起きている。パケットのトラフィックを“rate control”で抑制することで、流量の激しい増減が滑らかな変化に変わり、パケットの衝突を減らすことで全体としての効率が向上する。(幸いなことに、パケットの衝突では負傷者が出たり野次馬で渋滞したり保険請求のごたごたがあったり、ということはないのだ。)

PacketShaper の“rate control”機能を使い始めるとすぐに、ネットワーク効率は 95% から 99% という高い数字に跳ね上がった。接続の体感速度もはっきりと手応えが良くなった。

さて、次の段階は、しばらくの間 PacketShaper を走らせて私のインターネットトラフィックの状況についてどんなことを報告してくれるかを見ることだった。TidBITS Talk のメッセージをいくつか送信キューにいれておいて、私たちは夕食を食べに出かけた。戻ってきた時には、PacketShaper はさまざまの異なるタイプのインターネットトラフィック - SMTP、HTTP、FTP、POP、Timbuktu Pro など - を検知していた。これらは使用するポートのチェックやパケットヘッダを覗き見ることなどによって分別される。こうしてインターネットトラフィックのほとんどの一般的なタイプが自動的に検出され、分別できなかったタイプについては手動で調べることもできる。また、出入りするすべてのパケットが調べられてその結果がグラフで表示されるので、そのデータを多角的に検討することができる。主なプロトコルを面積で表わしたグラフをちょっと見ただけで、外向きの SMTP - つまり TidBITS Talk のメッセージや TidBITS 翻訳版の送付など - が実際私のネットワークのトラブルの最大原因であったことがはっきりした。PacketShaper の廉価版の機種はトラフィックの監視と結果の表示の機能のみに限定されている。こういう機種は問題点の分析に有効である。しかし私の場合は、問題点の解決もしたいと思っていたので、“shaping”機能(パーティションとポリシー)を持つ機種の PacketShaper が必要になった。(モニター機能のみの PacketShaper を購入した場合も、後日“shaping”機能を持つものにアップグレードできる。)

また高速道路の例え話に戻ってみよう。パーティションというのは、3人以上乗車中の自動車専用のカープール車線のようなものだ。PacketShaper は送信の目的地、送信の出発地、あるいはパケットのタイプなど、さまざまの条件に基いてパーティションを作成することができる。そしてその種のトラフィック専用に一定量の帯域幅を取り分けておくのだ。ちょうど高速道路でカープール車線が常時取り分けられているのと同じように。(ただし、実際の高速道路とは違って PacketShaper では車線無視のインチキはできない。)例えば私の場合には 56 Kbps 接続のうち 10 Kbps を外向きの SMTP 専用のパーティションとして設定することもできる。しかし、実はそれでは現実的な設定とは言えない。なぜなら他の帯域が完全に空いているような時間帯も多いのだから、そんな場合に 56 Kbps のすべてを外向き SMTP に割り当てないのは損だからだ。パーティションが役に立つ場合というのは、例えば音声のように帯域幅の一定量しか要求しないようなサービスとか、またはウェブのホスト会社が個々の利用者に利用可能な帯域幅の制限を課しているような状況だろう。

高速道路に固定の1車線を取り分ける代わりに、ポリシーという機能は異なる通信のタイプごとの優先順位を単純に変更する。あたかもパトカーや消防車がサイレンを鳴らし非常灯を点けて優先順位を上げるようにだ。他の普通の自動車たちは皆、道路の脇に寄って道を譲るので、こうした緊急自動車は渋滞に巻き込まれることもなく素早く移動ができる。PacketShaper でも同様で、私は内向きの HTTP(つまり私が見ているウェブページ)や内向きの FTP(つまり私がダウンロードするファイル)にサイレンを与えることで、外向きの SMTP(つまり TidBITS Talk のメッセージや翻訳版の送付など)よりも優先順位を高くした。この機能の実現のために必要な高速計算量は想像を絶するほどのもので、PacketShaper が専用のハードウェア・ボックスとして作られているのも、これが理由の1つだ。もしも PacketShaper が一片のソフトウェアに過ぎなかったら、オペレーティングシステムで起こっている他の事によってその高速計算が乱されてしまうからだ。

今説明した通りのポリシー設定を実施した結果、インターネットのパフォーマンスに関する私のトラブルは見事に消え去った。PacketShaper は静かにすべてのトラフィックを監視し続け、私が他の目的のために接続を必要としていない時にはすべての帯域幅を外向き SMTP に振り分けることもできている。私がウェブページのリクエストを出したりダウンロードを始めたりすれば、たちどころに PacketShaper は外向き SMTP のトラフィック量を絞り込んで、HTTP や FTP のパケットが最高速で私の Mac に到着できるようにする。外向き SMTP はインタラクティブなサービスではないので、その速度低下を感じることのできるような人間はどこにもいない。難点があるとすればただ1つ、出て行くメッセージの発送時刻が少しばかり遅れるということだけだ。(ここまでの翻訳:Mark Nagata)

ラッシュアワーには -- 私は、PacketShaper が問題を解決してくれたのでとても感謝していたが、何らかの形で PacketShaper の能力をさらに試せないものかとうずうずしていた。その機会は、Geoff のブロードバンド接続が突然に跡絶えてしまい私の家に 5 台のサーバが移設されたときにやってきた。突然、 PacketShaper はさらに沢山のトラフィックのタイプや量をか細い接続に詰め込むことになったのだ。

一番大事だったのはもちろん外向きの HTTP で、これは利用者に TidBITS 記事データベースの検索や TidBITS Talk アーカイブの閲覧を可能な限り最良の状態で行なえるようにしたいからだ。外向きの POP3 の優先度も上げて、Geoff の 19.2 Kbps モデム接続でもメールを読むのが楽になるようにした。そして次の週はずっと、時々高速のアクセスが必要だがめったに多くを占めるものではない Timbuktu Pro や FileMaker、そしてそのほかの接続のためにポリシー設定をいろいろ試してみた。

どの種類のトラフィックが送受信されているのかをグラフ表示するいくつかのカスタムレポートの設定も行ない、接続が正常にされているか確かめるためにこれらを定期的に更新し始めた。これには驚かされた。LetterRip Pro がメッセージを送出したり大きなファイルをダウンロードにつれ上下する変化の激しいパターンから、最大の値である 56 Kbps を保ったまままったく平らなネットワーク利用パターンまで一目瞭然だった。残念ながらその時は忙しすぎてこの記事のためにグラフを保存しておくことを考え付かなかったので、今お見せ出来る最良のものは復元した Geoff の ISDN 接続にサーバを戻した後のものだ。

<http://www.tidbits.com/resources/601/>

PacketShaper は具体的な数字も示したので、普通の日には 70 MB 程度のデータを送り出しているのに対し、Geoff のサーバを追加した後の最初の火曜日(最大のトラフィックの日)には 24 時間で 320 MB を転送したのも確認できた。私達の様なか細い接続には大量のデータだ。

インターフェースは困りもの -- PacketShaper のような製品にとって一番重要なのはもちろん内部のコードであり、見るとわかるように Packeteer はインターフェースにはあまり関心をはらっていない。基本機能は全て Web ベースのインターフェースからアクセスでき、様々なプラットフォームで動作させるには合理的な方法だ。Packeteer の技術者は JavaScript に大いに依存することを選び、その結果 Macintosh 版の Internet Explorer を使い PacketShaperを管理することが基本的に無理になってしまった。Mac 版の Netscape(少なくとも Netscape Communicator 4.7)ではほとんど動作したが、ウインドウをリサイズすると再描画され、そして PacketShaper インターフェースのある特定の、大抵は望む場所ではないページに移動させられる。Netscape はさらに、文字が小さすぎてほとんど読めないフォント表示の問題にも苦しめられる。悲しいことに、Packeteer の利用者の大部分は Windows か Unix を使っているので、 Richard は度々擁護するが Mac できちんと動作するようになる可能性は低い。

しかし基本的な動作の観点から言えば、Web ベースのインターフェースは極めて多くの柔軟性を提供するだろう。グラフに表示する時間の範囲を 3 時間前までのトラフィックや 4 日前、あるいは 2 ヶ月前までも変えるのは簡単だ。ポリシーやパーティションの設定も、自分が何をしているのか正確に理解するために広範囲に渡るマニュアルの説明が必要な場合があるが、比較的理解しやすい。

しかしながら、グラフィックインターフェースは歓迎するにしてもPacketShaper を真剣に使おうと思ったら Unix のようなコマンド行インターフェースを学ばないといけない。速いだけでなく、PacketShaper のデータに対しての問い合わせにもほとんど制限は無い。ある特定の時刻に FTP トラフィックのピークがどのマシンで起こったか知りたい場合はどうか?もちろんPacketShaper は知っているしそれに答えることもできるが、それはあなたが適切なコマンドを組み立てることができた場合だけだ。コマンド行インターフェースはまた、いくつもの変更を一度に行ないたいときにも役に立つ。

これは誰のために? -- 現実的に言えば、PacketShaper はエンドユーザーやインターネットへの接続が控えめでも充分な人のためにあるのではない。インターネットやワイドエリアネットワーク(WAN)への接続の要求が非常に大きく、そして帯域を広げることが高価だったりあるいは単に不必要な状況下で威力を発揮するだろう。例えば通常は 56 Kbps から 384 Kbps フレームリレー接続の国際 WAN 接続や衛星国際接続で PacketShaper を設置すれば、帯域の強化費用を払うのを避けたり延期したりすることが可能だ。もっと一般化すれば、ある組織(大きな会社、大学そして ISP 等)のユーザーが定期的に WAN あるいはインターネットのパフォーマンスに対して苦情を申し立てた時、いつでもPacketShaper はネットワーク管理者がネットワークで何が起こっているかを突き止めるのを助け、最大の効率が得られるよう操作できる。

大学は極めて広い帯域のインターネット接続を持っている場合がしばしばあるが、ここ数年帯域の要求が急激に増加するのを見てきただろう。一部分は、寄宿舎の部屋でピアツーピアサーバで動いている Napster とその後継者達のお陰だ。 PacketShaper を使えば、管理者は簡単に曲の交換に関するこのトラフィックのプライオリティを下げその他の大切なトラフィックに影響が及ばないようにできる。付け加えて、Napster の利用率が法的な災難ではっきりと減ってきた今、消えそうにもない音楽の共有トラフィックをどのサービスが Napster に代わって占めていくのかというようなことも、PacketShaper はネットワーク管理者に知らせることができる。

PacketShaper はまた、米国外ではありふれている、帯域の使用量に応じて料金を支払う場合には天からの賜物と言える。ギガバイトごとのデータ転送量に対し毎月料金がかかるなら、どのような種類のデータに対して、そしてどこからあるいはどこに転送されるデータに対して支払いをしているのか知りたいと思うに違い無い。PacketShaper ならこれら全てに答えられるし、高価な帯域が音楽の共有やストリーミングビデオで消費されていないか確かめるのにも役立つ。

最後に、Web ホスティング会社はしばしば PacketShaper を使って顧客に最低保証された帯域を提供する。これは、例えば極端に有名なサイトが一緒に設置されている他のサイトへのトラフィックを遅くしないことを保証する。加えて、PacketShaper のポリシーは対話的でないトラフィック、例えば大きなメーリングリストの SMTP 電子メールが、受け取るのを待っている人へのトラフィック、例えば Web ページやビデオ会議ストリームを確実に遮らないようする。

価格 -- 多くのハイエンドネットワークデバイス同様、PacketShaper はCompUSA の棚に陳列されているような物ではない。価格はトラフィックを監視できるかまたはトラフィックを調整できるかにより、また接続のサイズによって異なり、およそ $3,500 から $34,000 の幅になる(私が使用したユニットは$3,500 の部類で、T1 接続用には $8,000 程度が目安だ)。興味があってもっと詳しく知りたいなら Packeteer のWeb サイトに情報があり、加えて営業担当者に連絡を依頼するためのフォームもある(または最寄りのオフィスに連絡することも出来る)。

<http://www.packeteer.com/moreinfo/>
<http://www.packeteer.com/company/offices.cfm>

当然だが、私は皆さんに家から飛び出して PacketShaper を買うようにお勧めはできない。しかし、速くあるいはまた激しく使われているインターネット接続に責任のある人には間違い無く一見の価値がある。帯域を増やすことを考慮していながら毎月増えるコストに尻込みしているならなおさらだ。その“rate control”と優先付け機能の間で、PacketShaper は既存の接続をより十分に利用するのを助けることができ、それで帯域を増やすことを延ばすことができるかもしれない - そしてそれは権威者が言ったにもかかわらずまだ無料ではないのだ。(ここまでの翻訳:佐藤浩一)


tb_badge_trans-jp2

TidBITS は、タイムリーなニュース、洞察溢れる解説、奥の深いレビューを Macintosh とインターネット共同体にお届けする無料の週刊ニュースレターです。ご友人には自由にご転送ください。できれば購読をお薦めください。
非営利、非商用の出版物、Web サイトは、フルクレジットを明記すれば記事を転載または記事へのリンクができます。それ以外の場合はお問い合わせ下さい。記事が正確であることの保証はありません。告示:書名、製品名および会社名は、それぞれ該当する権利者の登録商標または権利です。TidBITS ISSN 1090-7017

©Copyright 2009 TidBITS: 再使用は Creative Commons ライセンスによります。

Valid XHTML 1.0! , Let iCab smile , Another HTML-lint gateway 日本語版最終更新:2009年 4月 1日 水曜日, S. HOSOKAWA