Leopardに戻しました。

Snow Leopard+OsiriX 3.6の組み合わせですが、spotlightの検索が何かおかしい。
鈍いし、以前のような結果が得られないのです。（余計な候補が出てしまいます）
更に、落ちる確率も高いようです。
結局、Leopardに戻しました。

OsiriX3.6にとってはまだSnow Leopardは早すぎるようです。

OsiriX 3.6+Snow Leopardにまった！！

Mac好きなら、もちろん、Snow Leopardにしましたよね。
しかし、OsiriXを使っているあなた、もう少し待った方がいいかもです。
OsiriX 3.6+Snow Leopardですが、なんか動作が鈍いような、検索が不安定みたいです。
現在のところ、OsiriX 3.6+Leopardの方が安定しているようです。
また、しばらく使った感想としてもOsiriX 3.6は安定したバージョンなのは確実なようです。

OsiriX 3.6いいかも

OsiriX 3.6にしてから、妙に調子いいみたいです。
今回のWhat's newに
Default DB can receive images in background if another DB is selected
とあるのですが、関係あるのかな？

さらにSnow Leopardを入れましたが、問題ないようです。
Snow Leopardですが、以前と比べて、違和感がないというか違いがあまりわからないというか。
拍子抜けした感じです。

VERSION 3.6 NOW AVAILABLE

OsiriX VERSION 3.6(^O^)/ 出てます。

What's new in version 3.6 ?

- Certified for Snow Leopard compatibility (MacOS 10.6)
- New 'AutoCropping Algorithm' technology in 3D VR/MIP -> Between 20% to 100% faster rendering speed
- minIP for 3D MPR
- C-GET SCU/SCP (Dynamic IP address DICOM transfers)
- Settings for compression per modality
- JP2000 compression support, with quality level option
- Support for OpenJPEG JPEG2000 encoding
- OpenJPEG is 2.2x times faster : OpenJPEG is now faster than JasperLib
- Better compression/decompression performances when receiving DICOM images
- Soundex (search on pronunciation, instead of orthography) when searching for patient names
- Series comments/state displayed in Web Server
- Display Same Patient with gray color in Database window
- Better printing resolution for large images
- Default DB can receive images in background if another DB is selected
- Better DICOM CD/DVD reading
- Apply a route rule on database selection (contextual menu)
- Save and load DICOM printers list
- Multiple bugs corrections
- Much better support for DICOM Encapsulated PDF



ちなみに
OsiriX 3.5 and higher are fully compatible with Snow Leopard MacOS 10.6

You can upgrade to Snow Leopard !　　　　

Snow Leopardは本日発売です。買いに行かなくては。(^-^)/

BonjourとDHCPとダイナミックドメインネームシステム(DDNS)

Wikipediaからの引用ですが、欠点の所に、「Bonjourは、基本的にLAN内でしか利用することができず、原則的にルータを越えることができない。ただしこれは、DHCPとダイナミックドメインネームシステム(DDNS)を用いることで解決可能であり、その二つを用意すればルータを越えた運用が可能になる。ただし、IPv6ではこの限りではない。」 とあります。
DDNSをどのように使えばいいのでしょうか。
またはIPv6を使うのはどうすればいいのでしょう。

どなたか教えて下さい。<(_ _)>

概要 [編集]

語源はフランス語で「こんにちは」の意味。旧称のRendezvousは同じくフランス語で「待ち合わせ」の意味。
Bonjourは元はIETFの中で検討されていた「Zeroconf」という技術がベースになっている。米Apple社はこれを独自に発展させ、仕様を公開することにより、現在では「Zero Configuration Networking」としてIETFにより標準化されている。
ここで「ゼロ・コンフィギュレーション (Zero Configuration)」とは、「何の設定も行わず機器を使用可能にする」技術のことである。
Appleには元々、ゼロ・コンフィギュレーション技術としてAppleTalkというプロトコルがあった。これは何らかの機器をLANに接続すると、アドレスと名前がその機器に自動的に割り振られ、ユーザは何の設定も行うことなくその機器へのアクセスが可能になるものである。配線すればすぐにネットワークプリンタなどが使用可能になるメリットはあったが、反面、LANに接続されている機器が常にネットワークに新しく接続された機器がないかどうかを探索し続けるため、ネットワークに負荷がかかりがちになるという欠点もあった。
LANの主流がTCP/IPをベースとしたイントラネットに移行してくると、AppleTalkとTCP/IPを混在させるためのMacIP、IPTalk、EtherTalkといった技術が登場した。結果としてユーザと管理者は複雑な設定を強いられることになった。その後AppleはAppleTalkを段階的に廃し、TCP/IP上でのファイル共有(AFP over TCP)やサービス発見(SLP)を導入したが、設定は複雑なままであった。
こうした経緯からAppleは、AppleTalkを置き換える技術としてBonjourを開発した。BonjourはTCP/IP上で動作し、AppleTalkと同様の使い勝手を持ちながら、遥かに低い負荷しかネットワークに要求しない。
「何の設定も行わず機器を使用可能にする」ことを目指している点では、Sun MicrosystemsのJiniやMicrosoftのUPnPと似ている。
機能 [編集]

Bonjourの代表的な機能はIPアドレスとホスト名の自動割り当て、サービスの自動探索である。ネットワークに接続された機器はDHCPサーバのようなIPアドレスを割り当てるサーバも、DNSのようなネームサーバも、ディレクトリサーバも必要としない。機器がBonjourネットワークへ接続するとIPアドレスは自動的に割り当てられ、ホスト名は各機器にあらかじめ設定されたものが利用され、提供可能なサービスはホスト名と共に通知される。
IPアドレスの割り当てにはAutoIPの技術が使われる。IPv4のネットワークへ接続された場合、Bonjour対応機器は169.254.0.0/16の中から空いているアドレスを探索し、それを自らのIPアドレスとする。IPv6の場合、LANインターフェースに自動で割り当てられるリンクローカルアドレスがあるので、それを利用する。
ホスト名は基本的に、各機器が名乗るホスト名を利用する。名前のルールは「マシン名＋サービス名＋プロトコル名＋ドメイン名」である。マシン名はユーザがその機器に対して設定したものを使い、サービス名にはその機器が提供するサービスが、プロトコル名にはTCP/IPの場合「._tcp」が、ドメイン名には「.local」が入る。
ホスト名の探索にはマルチキャストDNS (UDPポート5353) を用いる。ホスト名を探索する際にはネットワークに接続された機器全てに対してホスト名を問い合わせ、一致したホストに対して接続を行う。ただしそのまま実装したのではネットワークにかかる負荷が大きくなってしまうため、あらかじめホスト名をキャッシュするなど負荷を減らす工夫が行われている。
提供可能なサービスの一覧は、ホスト名の問い合わせにマルチキャストDNSが用いられていることを利用し、DNS resource recordsに入れられて通知される。なおこの「サービス」には、プリント機能などハードウェアが提供するサービスのみに留まらず、音楽や画像の配信、インスタントメッセージングなど、ソフトウェアが提供するサービスも含まれる。
Bonjourの特色は、デバイスではなくサービスを中心に据えていることである。特定のデバイスに対し提供しているサービスを問い合わせるのではなく、目的とするサービスを提供しているデバイスを探索するのである。例えばあるサーバはWebサーバかもしれないが、同時にFTPサービスを提供しているかもしれない。ひとつのデバイスが複数のサービスを提供していることは珍しくないし、負荷の分散を目的にサービスを提供するサーバを別のデバイスに移動させることもある。重要なのはデバイスではなくサービスであるという考え方である。
まずホスト名を解決しIPアドレスを用いて特定デバイスにサービスを問い合わせるのではなく、いきなり目的とするサービスを提供しているデバイスを探す。ネットワークに接続されたデバイス全てに対しマルチキャストで「FTPサービスを提供しているサーバはどれ？」と訊ねれば、該当するデバイスは手を挙げるので、それからホスト名を解決してアクセスを試みるのである。
負荷を減らす工夫 [編集]

AppleTalk最大の欠点は、何よりもまずネットワークにかかる負荷であった。Bonjourではその負荷を減らすべく、様々な工夫がこらされている。
Bonjour対応の機器が新たにネットワークへ接続されると、その機器はまず自らにIPアドレスを割り当てた後、自らのアドレスとホスト名、さらに提供しているサービスの種類をネットワークへマルチキャストする。他の機器ではその情報をキャッシュし、次回のホスト名やサービスの問い合わせの際には、まずそのキャッシュされたデータを参照するようになる。
ただしそのままではネットワークから機器が取り外された場合に対応できず、動的に再構成されるネットワークには対応できなくなってしまうので、データは常に更新され続ける必要がある。このため、ネットワークに接続された機器は一定時間毎にマルチキャストで提供可能なサービスの一覧をネットワークの全デバイスに要求する。このマルチキャストは回を重ねる毎に間隔が長くなるように設定されており、最初のマルチキャストはネットワークに接続された時に、2回目はその1秒後に、3回目はさらにその2秒後、4回目は4秒後、5回目は8秒後、6回目は16秒後と、時間は指数関数的に長くなっていく。この間隔の最大値は4096秒で固定されており、それ以上には大きくならない。
このように間隔が段々と長くなっていく理由は、ネットワークへ接続される機器は短時間で取り外されるものと長時間接続されるものの二種類に大別することができ、その中間というものがほとんど存在しないからである。例えばネットワークプリンタなども使用する時だけ電源を入れるか、あるいは朝から晩まで接続しっ放しかの二種類であり、数分毎に接続切断を繰り返すケースはまずない。
こうしてマルチキャストされたデータは各ホストにキャッシュされる。各機器はネットワークに対して問い合わせを行う前にまずこのキャッシュされたデータを参照するようになっている。キャッシュに目的のデータがなかった場合はネットワークに対してマルチキャストで問い合わせを行うが、該当するアドレスやホスト名、サービスを提供している機器はその返答をやはりマルチキャストで行う。該当しない機器はもちろん沈黙を守るが、マルチキャストされたデータはもちろん受信しており、同様にそのデータをキャッシュに加えてデータベースを更新する。
あるホストがネットワークに対してサービスの一覧を要求した場合、問い合わせのパケットにはそのホストが「すでに知っているサービスの一覧」が含まれる。例えばネットワークにはすでに10のプリントサービスが存在し、問い合わせを行うホストがそのことを知っている場合、問い合わせのパケットにはその旨が記述される。リストに載っているプリントサービスは沈黙を守り、リストに載っていないプリントサービスのみが返答を行う仕組みである。
このようにBonjourは、データを可能な限りキャッシュし、ネットワークを探索する際にはまずそのキャッシュを参照することでネットワークへかかる負荷をギリギリまで減らしている。もちろんマルチキャストによる問い合わせが行われない場合に比較して負荷は高くなる傾向にあるものの、問題ないレベルに収まることがほとんどである。
欠点と制限 [編集]

Bonjourにはもちろん欠点や制限も存在する。まずBonjourは、基本的にLAN内でしか利用することができず、原則的にルータを越えることができない。ただしこれは、DHCPとダイナミックドメインネームシステム(DDNS)を用いることで解決可能であり、その二つを用意すればルータを越えた運用が可能になる。ただし、IPv6ではこの限りではない。 なお、Mac OS X v10.5においてBack to My Mac（どこでも My Mac）と呼ばれる機能が導入され、.Macのアカウントを持つユーザは広域でもホスト/サービスを参照できるようになった。実際この機能はDDNS等の技術を用いて実現されている。
またBonjourは、イベント制御の機能が弱い。例えばUPnPではきめ細かいイベント制御が可能になっているものの、Bonjourではこの部分にマルチキャストDNSやDDNSしか利用できないため、細かなコントロールを行うことができない。プリンタの制御についてはIPPやLPRを用いることが決まっているが、その他の機器についてはまだ仕様が策定されておらず、検討中となっている。
対応機器の少なさも悩みである。UPnPと比べ、Bonjourは対応している機器が少ない。アップルは"AirTunes"（無線LAN経由での音楽再生機能）を搭載したAirMac Expressなど、Bonjourの機能を生かした製品をリリースしているが、サードパーティーでは、現在対応を表明しているメーカーはほとんどがプリンタメーカーである。
UPnPが基本的にハードウェアのみに用途が限られているのに対し、Bonjourはハードウェア・ソフトウェアを問わず利用することができる。Bonjour対応ソフトウェアとして最も普及しているのはアップルのiTunes(iTunes同士で音楽共有ができる)とSafari(Bonjourに対応したWebサーバを自動的に探索しリストアップする)であるが、アップル社以外のソフトウェアではAirfoil（iTunes以外のソフトウェアでAirTunesを可能にする）、Camino、シイラ (ウェブブラウザ)、RealPlayer程度であまり活用されているとはいいがたい現状である。
またUPnPも開発過程こそ非公開であるものの、仕様はロイヤリティフリーで公開されているので、Bonjourがオープンソースであることは現在のところあまり目立ったアドバンテージにはなっていない。