MOSA Multi-OS Software Artists

「Wonderful Server Life」　　第41回　　田畑 英和

　 〜DHCP編〜

　まずは前回の記事の補足から始めます。前回の記事で4Gbに対応した新しいFiber Channelのカードを紹介しました。新しいカードには2ポートと4ポートの2つのモデルがあります。カードに付属しているケーブルの本数について前回の記事では「ポート数にかかわらず新しいカードには2本ずつケーブルが付属しています。」と紹介しましたが、4ポートモデルにはケーブルが4本付属していることが分りました。
　ちなみにXserveですが、CTOを行えば2つある拡張スロットにそれぞれFiberChannelのカードを選択することが可能です。ただしCTOでは両方のスロットに4ポートのカードを選択することはできず、4ポートのカードが選択できるのは片方のスロットのみになっています。2ポートのカードであれば、両方のスロットで選択することが可能です。

◇DHCP
　さて、今回からMac OS X ServerのDHCPについて解説したいと思います。まずDHCPの役割ですが、DHCPを使えばコンピュータのネットワーク設定を自動化することができます。TCP/IPの通信を行うにはIPアドレスなどのパラメータを設定する必要がありますが、DHCPを利用することにより各コンピュータごとにネットワーク設定を手動で行う必要がなくなり、コンピュータをネットワークに接続すればDHCPによりネットワーク設定が自動的に行われるようになります。
　具体的にどのような設定が自動的に行われるかですが、基本的なパラメータとして以下の項目がDHCPにより提供されます。

・DHCPにより自動設定されるネットワーク設定の項目
　　- IPアドレス
　　- サブネットマスク
　　- ルーター
　　- デフォルトドメイン
　　- ネームサーバ　　
※これ以外にもDHCPで提供可能な項目があります。

　これらのパラメータはクライアントコンピュータ側の「システム環境設定」の「ネットワーク」で手動で設定できる項目ですが、DHCPを使えば自動的に設定が行われます。もっとも、クライアント側ではあらかじめDHCPを使用するように設定しておく必要がありますが、特に設定を変えなければ、Mac OS XはデフォルトでDHCPを参照するようになっています。

◇DHCPの設定
　Mac OS X ServerでのDHCPの設定方法ですが、他のサービスと同様に「サーバ管理」を使用します。「サーバ管理」でDHCPの設定画面を表示しますと、まずサブネットの一覧画面が表示されます。初期状態ではなにも登録されていませんが、DHCPは設定を複数登録することができ、各設定はサブネットと呼ばれています。設定画面ではまずサブネットのリストを管理することができます。
　登録したサブネットを実際に有効にするにはサブネットの一覧画面で「使用可能チェックボックスをチェックしておく必要があります。

・「設定」＞「サブネット」
http://homepage.mac.com/htabata/MXS10.3/img/DHCP/DHCP_ADMIN_01.png

◇「一般」設定
　新規にDHCPを設定する場合は、「サブネット」設定画面左下の「＋」ボタンをクリックしてサブネットを追加します。サブネットを追加すると、サブネットの詳細画面が表示され、ここで様々なパラメータを登録していきます。サブネットの詳細画面はさらに「一般」「DNS」「LDAP」「WINS」の4つの画面から構成されています。
　「一般」画面から設定を始めることになりますが、ここではまず任意の「サブネット名」を入力します。そして、クライアントに配布する「IPアドレス」「サブネットマスク」「ルータ」などのパラメータを設定します。「IPアドレス」ですが、一般的にDHCPサーバは複数のクライアントにネットワーク情報を提供しますので、各コンピュータにIPアドレスが行き渡るように、十分な数のIPアドレスの範囲を指定します。もちろんここで指定するIPアドレスの範囲は他のところでは使用されていないアドレスを指定する必要があります。
　またDHCPのサブネットを複数設定する場合には、それぞれのサブネットで使用するIPアドレスの範囲が重複しないように注意してください。

　「一般」の設定画面では他にも「ネットワークインターフェイス」の設定ができます。複数のポートをもったサーバを使用している場合、どのポートからDHCPを提供するかを指定することができます。利用可能なポートは、自動的にポップアップメニューに表示されますのであとは適切なものを選択するだけです。
　あと「リース期間」という設定がありますが、DHCPではクライアントにネットワーク情報を一時的に貸し出します（つまりリース）。この貸出し期間をどの程度の長さにするのかという設定が「リース期間」です。実際にはリース期間が過ぎても引き続き使用中であればリースの延長がおこなわれますので、突然ネットワークが使えなくなるといったことはありません。

・「設定」＞「一般」
http://homepage.mac.com/htabata/MXS10.3/img/DHCP/DHCP_ADMIN_02.png

◇「DNS」設定
　「DNS」の設定画面では、クライアントコンピュータに設定するデフォルトの「ドメイン」および「ネームサーバ」の設定を行います。ネームサーバは複数設定することもできます。

・「設定」＞「DNS」
http://homepage.mac.com/htabata/MXS10.3/img/DHCP/DHCP_ADMIN_03.png

　それでは次回も引き続きDHCPについて解説いたします。

つづく　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

藤本裕之のプログラミング夜話　#110

　前回の件，NSTableView に対し，NSArraryController のバインディングを使ってデータを表示している場合，その個々の要素のドラッグ＆ドロップはどう実現すればいいのか，という問題について未だメールは来ていない。これ，忘れたわけぢゃなくてオレも日々考えてるし（ちょっと誇張あり），見つかったらこの連載ででも他の方法ででもお知らせする所存であるので，皆さんも思いついたら意地悪しないで教えてくだされ。

　で，今回から新シリーズ。「サービス」をサポートしようという話。
　もしかすると知らない人もいるかもしれないが，Mac OS Xで稼働するアプリケーションのうち，ユーザインタフェースを備えたプログラムのアプリケーション・メニュー（普通アップルメニューとファイルメニューの間にある，そのアプリケーションの名前がタイトルになってるメニューのことね）の中に「サービス」という項目がある。
　……開いてみた？　あるでしょ？　例えばこの原稿のこのパラグラフを選択状態にして「スティッキーメモを作成」を選ぶと……ほら，スティッキーズが起動して選択された文字列を内容とする新しいメモができたでしょ？　「サービス」とは，こんな風に稼働中の他のアプリケーションから文字列などのパラメータを受け取ってなんらかの処理を実現するしくみなんである。
　もちろんサポートする処理はアプリケーションによって違う。スティッキーズは文字列を受け取って新しいメモを作るけど，Mail.app は選択範囲を送付先のメールアドレス，または内容として新規メールを作ってくれる。Apple 標準ぢゃないけど Jedit X のサービス機能は強力で，スティッキーズ同様新規書類を作ってくれるほか，選択部分の全角・半角文字を統一したり，選択部分から改行コードを抜いてくれたり，逆に強制改行でケタ揃えしてくれたりして，しかもそれをペーストボードに返してくれちゃう……。あなたのアプリケーションではどんなサービスが提供できるだろうか？

　具体的なインプリメント作業に入る前に，これがどんなしかけで動いているかを確認しよう。Jedit X がサービス結果の文字列をペーストボードに返してくれることでも判るように，基本的にはペーストボードを介してデータを受け渡すアプリケーション間通信である。
　まずサービスを要求する側のアプリケーション（サービス・リクエスターという）上でユーザがサービスメニューからなにかのサービスを選ぶ。するとリクエスターに対して「copy:」メッセージが送付され，選択部分がペーストボードに入る。選択部分がないときはどうなるって？　百聞は一見に如かず，やってごらんなさい。……やってみた？　ごらんの通り，なにも選択されていないときはサービスメニュー自体が選択できない。
　次にサービスする側のアプリケーション（サービス・プロバイダーという。
オレが乗る東急バスの運転手さんと同じだ）が，起動していなければ起動され，サービスしなさいというリクエストが渡る。
　プロバイダーはこれを受けてペーストボードから元データを読み，処理を行う。例えばさっきスティッキーズにやらせた新しいメモの作成みたいに，リクエスター側に返事をする必要がない場合はそれでおしまい。Jedit X みたいなケースだと，処理の結果をペーストボードに戻し，リクエスターに「お待ちどおさま，ご主人様」と，メッセージを送る。「ご注文のほう，これでよろしかったでしょうか」とは言わない。これ，日本語変だからね（そういう問題ぢゃないが）。
　で，細かい話をすると，スティッキーズのような返事の要らないサービスが「プロセッサー型」，Jedit X のような……って，Jedit X には「プロセッサー型」のサービスもあるんだけどね，処理の結果をペーストボード経由で戻すタイプを「プロバイダー型」のサービスということになっている。

　では次回から具体的に「サービス」のインプリメント方法を解説していくので，皆さんは自分のアプリケーションでどんなサービスを実現してやろうか，とあれこれ構想を練ったりしていていただきたい。ほんぢゃ。
　　　　　　　　　　　　　　　　　　　　　　　　　　　　（2007_03_07）

高橋真人の「プログラミング指南」第108回

プログラマのためのオブジェクト指向再入門(16)

〜GUIアプリの基本構造(2)・イベントループ（続き）〜

　こんにちは、高橋真人です。早速続けます。
　イベントループという場合、当然ループが必要になるわけですが、単に空回りをしていればよいわけではもちろんありません。“イベント”ループというからには、イベントに対処するための仕組みが必要です。
　ちなみにイベントというのは、ユーザーがキーボードをタイプしたり、マウスをクリックしたり、それまで表示されていなかったウインドウが表に出てきたためにウインドウの中身を描画しなければならなくなった時などに、主に外部からアプリケーションに対して送られてくる処理要求をするための仕組みの一つです。
　「主に外部から」と書いたのは、アプリケーションが自分自身に対してイベントを送ることもできるからです。また、「仕組みの一つ」と書いたのは、イベント以外にもアプリケーションに対して処理要求をする仕組みはいくつかあるからなのですが、余りその辺を厳密にやると話が複雑になるのでアバウトにとらえておいてください。
　さてこの断続的かつ不定期に送られてくるイベントですが、原則としてこれらは「やってきた順に処理する」ことになっています。「順番に処理する」と言えば、ここは「キュー」の出番ですね。システムは、イベントキューというイベント専用の待ち行列の格納エリアを持っていて、イベントをやってきた順に並ばせます。
　Mac OS 9時代のToolboxでは、このイベントキューからデータを取り出すためにWaitNextEvent()というAPIを使っていました。これをループの中で一回以上呼び出すことで、イベントキューの先頭から順にイベントを取り出し、それを順に処理していたというわけです。
　このように、プログラムが自らイベントを取り出すということは、「どんなイベントがやってきているのか」をいちいち把握するためにはいいのかもしれませんが、そんなのが役に立つのはデバッグの時ぐらいのもので、むしろ自分に関係のないイベントに対してまでいちいち対処してやらなければならないのは、結構な手間でしたし、イベントの処理の扱いになれないと、このイベントループを止めてしまう（つまり、一つのイベントの処理にずっとかかりっきりになっている）ことで、プログラム全体の流れを止めてしまうことになったのです。
　それでも、Mac OS Xのようなプリエンティブなマルチタスクのシステムならば、その影響はあくまでプログラムの内部だけの話で済むことが多いわけですが、OS 9のシステムでは一つのイベントの処理を誤ったことで、マシン全体の動きを止めてしまうことにも容易になり得たため、それなりに深刻な問題でした。
　Carbonと共に登場してきたイベント方式である、その名もCarbonイベントモデルの場合は、イベントの処理は基本的にはシステムにお任せで行います。つまり、イベンキューからのイベントの取り出しをプログラムが行うことはいたしません。
　だとすると、どうやってプログラムはイベントを受けることができるかというと、ハンドラという仕組みを使うのです。イベントハンドラというものをインストールすると、システムの側から必要に応じて呼び出してくれる仕組みになっています。ハンドラは好きなだけいくつでも登録できますし、ハンドラごとに「どんなイベントが起こった時に呼び出してほしいか」という指定を一つ以上行うことができるようになっていますから、かなりきめ細かな制御をすることも可能です。
　ちなみに、イベントというものにどんな種類があるのかということについては、以下のヘッダファイル（かなり長いので折り返しています）を見てみるとよいでしょう。かなり多くのイベントが定義されているのを知って驚かれる方も多いと思います。

/System/Library/Frameworks/Carbon.framework/Versions/Current/
Frameworks/HIToolbox.framework/Versions/Current/Headers/
CarbonEvents.h

　あくまでも上記はシステムが定義しているイベントということであって、これ以外にも自分で独自のイベントの種類を定義して使うことも可能です。

　さて、プログラムとしては「自分の関心のあるイベントに対してだけ」ハンドラを登録しておけばよい、ということですが、それは裏を返せば「自分に関心のないイベントの処理はシステムがやってくれる」ということになります。
　たとえばウインドウに関わるイベントの場合、ウインドウを生成するAPIであるCreateNewWindow()のパラメータにkWindowStandardHandlerAttributeという属性を指定してやることで、ウインドウの基本動作に関してはシステムにすべて任せてしまうことができるのです。さらにNibファイルでウインドウを作る場合に至っては、単にチェックボックスを一つ選択状態にしておくだけでいいのですから、実に簡単です。
　もっとも、Mac OS 9時代のプログラミング経験のない人や、Cocoaしかご存知のない方にとっては、何が簡単なのかがあんまりピンと来ないかもしれません。何しろOS 9のころは、ユーザーがウインドウを閉じるためにクローズボックスをクリックした時のような極めてありふれたケースですら、決まりきった処理コードをいちいち記述しなければならなかったわけですから。

　まあ、昔話はほどほどにして先に進めますが、通常、アプリケーションを作る場合、特にGUIアプリケーションであると起動時にやらなければならないことがいくつかあります。
　とは言えCarbonではOS 9時代に比べると、やることはそんなに多くありません。InitCursor()という何故かいまだに残っている初期化のためのAPIを除けば、メニューの構築、必要なウインドウの用意など、何のためにするのかが明確な初期化の処理を必要とするだけで、一見したところ「これは、何のために必要なの？」というようなものはまずありません。
　起動後のGUI部品の初期化が終われば、あとは必要に応じてハンドラのインストールをしておくだけ（まともなアプリの場合は、環境調査などの処理も必要に応じてやらねばならないでしょうが）。
　最後にRunApplicationEventLoop()を呼び出して、イベントループを走らせれば、残りはシステムがよきにはからってくれます。

◇MOSAからのお知らせと編集後記は割愛します◇