送信ウィンドウのユーザリストのカラム表示非表示設定と、オンラインアップデートの機能に関して、Mac OS X 10.4 での動作に問題が確認されているためです。

私自身は 10.4 環境（PowerPC Mac が必要なので…）はもう持っていませんが、世の中的には 10.4 はまだ現役といえるだけの稼働シェアがあるようで、基本的な重要機能のいくつかが欠けたまま開発を終了したくないと考えています。

幸い、 10.4 環境でのベータテストとデバッグ情報の収集にご協力して頂ける方がいらっしゃいますので、調査を進めることができており解決に向かっています（おそらく…）。

上の送信ウィンドウは随分大きくリサイズしてありますが、表示できる全カラムを表示して見えるようにしたものです。普通はもっと小さいウィンドウサイズで使われていると思います。表示できる幅は限られるので、自分に必要な情報だけ表示できるように、カラムの幅の変更、順序の入れ替え、表示非表示の切り替えが可能になっています。

カラムの表示非表示はメニューから指定します。

私はユーザ、グループ、ホスト、バージョンを表示しています。

6月初旬の予定がまだリリースできていませんが、来週には新バージョンをリリース出来る予定です。

いきなり別の方向性に飛ぶつもりはなくて、あくまでこれまでのバージョンを使っていた方にも、Windows 版から移行してきた方にも違和感のない印象でありつつ、Mac OS X らしいものに変更したつもりです。これぐらいの変更だと開発環境をインストールしている人であればコンパイル無しにできるので、やっている方もいるのではないかとか思いますが…。

次のバージョンは、自動アップデートチェック機能を組み込んで、6月初旬にはリリースしたいと考えています。

送信ウィンドウ。

現在の送信メッセージウィンドウはこんな感じ。周囲の余白が邪魔です。
（モザイク見苦しくてすみません）

新しい送信メッセージはこんな感じ。以前よりは Mac OS X らしくなりつつ、急激な変化にはならないし Windows 版からの乗り換えの人にも違和感はないと思います。添付ファイルのボタンは左下に移動しました。無駄が排除され同じウィンドウサイズで情報量が増えたので実用的でもあります。ちなみに Windows 版はこんな感じ（WindowsXPの場合）。これはバージョン 2.0x系ですが、Mac OS X 版を最初につくったころは 1.2x 系でしたので、ユーザリストはこんな風にはカラム化されていませんでした。

受信ウィンドウ。

現在の受信メッセージウィンドウはこんな感じ。こちらも周囲の余白が邪魔です。
新しい受信メッセージウィンドウは閉じるボタンを廃止し、添付ファイルのボタンを送信メッセージと同じく左下に移動しました。

閉じるボタンは Windows 版にあわせて配置していましたが、冗長だし Mac のアプリでは普通用意しないものなので気になっていたため、今回廃止しました。
ちなみに Windows 版はこれ。

おまけ。

2002 年に最初に公開したときの v0.1 のスクリーンショット。Mac OS X 10.1.2 だったみたいです。

やはり今のバージョンとほぼ同じレイアウトですね、ファイル添付をサポートした事による変更ぐらいしかされていないw。OS X も今となっては凹凸が多くてちょっとうるさい UI ですね。

バージョンアップしました。ログ機能を利用されている方は重要な不具合が修正されているので是非更新してください。

• http://ishwt.net/software/ipmsg/

v0.9.2 の修正でデグレードが発生していました。ログ出力機能で各レコードに記録される送受信日時が年月日（しかも英語の逆順表記）のみになって時刻が消えていました。ログなので日常的な利用をされている方には影響が大きいと思い、取り急ぎその点だけ修正したものをリリースしました。

次バージョン向けの修正をしていて気がついた不具合です。次バージョン向けの状況はまた別エントリにて報告します。

• IP Messenger for iPhone – ミワラボ

開発者が増えるのは良いことだと思います。

Mac 版と開発環境が近いので iPhone 版について要望を頂いたこともありましたが、iPhone の IPMsg は使う機会がないので（会社は無線 LAN に個人のスマートフォンを接続させてくれないので…）、自分で利用できないというのもあって開発には着手できませんでした。また、土日は家族中心でなかなか個人の開発の時間がとれない状況なので、Mac 版と両方メンテナンスするのも少々難しい。

というか Mac 版やることたくさんあるんだから、とっとと進めろよという話ですねそうですね。
開発の遅さで Tweetie for Mac に親近感を覚える今日この頃w。

以前「今後の計画」と題してエントリした内容は、今になってみれば削除したいぐらいまるで計画通りに進んでいないわけです。マイルストーンを置いて自分を追い込んだほうが事が進むかと思って書いてみたのですが、思ったようには進みませんでした。ということでここでは期日は決めずに諸々考えていることを。

まず最初に実現したいこと。

Sparkle という有名なフレームワーク（ライブラリ）を組み込んで、自動アップデートチェックの仕組みを入れます。

以前公開していた別サイトでは、ISP のホームページスペースに置いてアクセスカウンタを設置している程度だったので、いったいどれだけダウンロードされて使われているのか把握できていませんでした。このサイトではダウンロード数はカウントできるようにしているので初めて計測できたのですが、0.9.1 と 0.9.0+ を公開してから 0.9.2 を公開するまでの 4 ヶ月間で、7,900 ダウンロードされています（0.9.1 が 5,600、0.9.0+ が 2,300）。月に 2,000 弱もダウンロードされていることになります。これには個人的にはびっくりしました、思っていたよりもずっと多いという意味で。

これだけ多くの方がダウンロードして、その全部とはいいませんがある程度の割合の方が利用してくれていると考えると、ソフトウェアのアップデートを確実に伝え、できるだけ最新版を使ってもらいたくなります。相当マメな人でない限り、何もなければインストールしているソフトウェアのアップデートは、OS やマシンの入れ替えのタイミングで最新版かどうかチェックする程度でしょう。自動アップデートチェックの仕組みを用意することで、タイムリーに多くの方にアップデートを知らせ、適用してもらうことができるようになります。

まずは自動アップデートチェックを組み込むことを最優先してなるべく早期にリリースし、以後の修正や機能追加を細かくリリースするようにしていきたいと考えています。

既知の不具合。

0.9.2 には含められなかった既存の不具合があります。難しい問題ではないものもあり、不徳のいたすところであります。

• 返信しても受信ウィンドウが消えないことがある
• 制御コードを含むファイル名を添付ファイルとして送信できない
• ユーザ一覧を更新するとユーザが消えてしまうことがある

これらは自動アップデートチェックを組み込んだものをリリースしてから、順次対応の上リリースしていくつもりです。不具合情報は BTS で管理しています。

• IP Messenger for Mac OS X 不具合情報

もし利用していて不具合らしき現象に気づかれた場合、不具合報告フォームよりお知らせ頂けると助かります。Twitter でもかまいません。

なお、中国語（に限らず、たぶんマルチバイト文字符号を用いる言語）のメッセージ送信でクラッシュする（らしい）件については、IP Messenger の通信プロトコル（通信手順）が日本語の Shift_JIS を正式な文字符号としているため、仕方のない面があります。私としては正規の通信プロトコル以外に対応することは混乱につながると考えているので、正規プロトコルが多言語対応しない限り何らかの対応をするつもりはありません。「私は」そう考えるだけで他人に強要する気はありませんので、ソース公開もしていますし必要な方は改造版をつくるなりしてご利用頂ければよいというスタンスです。

機能改善。

開発再開してからは不具合修正のみに注力してきましたが、自動アップデート機能搭載後は、機能の追加やユーザインタフェースの改善なども取り組んで行きたいと思っています。

• 暗号化通信機能
• ユーザ検索機能（お気に入り機能なども含む）
• ユーザ一覧のテーブル表示
• ユーザインタフェースを Mac らしく改善（Windows クローンの適度な解消）
• Growl 対応
• ログの記録参照検索の根本的な改善

一気にというわけではありませんが、このあたりを優先的に考えていこうかと。対応する項目は自分が以前から気になっているものや、要望として連絡を頂いたものがどうしてもプライオリティが高くなります。搭載のお約束はできませんが、機能要望がありましたら、問い合わせフォームからお知らせ下さい。こちらも Twitter からでもかまいません。

機能要望についても BTS で管理しています。将来機能として挙がっているか、状況がどうかなどを見ることが出来ます。

• IP Messenger for Mac OS X 機能要望

その他。

10.4 のサポートをいつやめるかについては、今のところまだ続けるつもりでいますが、状況次第です。開発面からの違いとしては、10.5 以降のみサポートにすると、開発言語やライブラリ、64bit 対応などの面においてかなり開発がしやすくなります。ただ、問い合わせ等でも 10.4 で（あるいは 10.4 でも）利用されている方は少なくないようなので、どこかで 10.4 の最終バージョンを決めるにしてももう少し使い勝手など改善してから、と欲がでます。おそらく、新たな機能を追加するにあたって 10.4 が明確な足かせになってくると考えることになるのかなあと思っています。

他にもこまごまと思っていることもありますが、あげつらっても全然実現できなそうなので今回はこの辺で。

バージョンアップしました。

• http://ishwt.net/software/ipmsg/

前回から 4 ヶ月と間があいたにも関わらず、不具合修正中心のリリースです。でも地味に便利な改善もあります。

修正内容。

自動一覧更新。

今回のバージョンアップで意外と便利な部分が、ネットワーク接続状況の変化によってユーザ一覧が自動で更新される機能です。これは利用形態によっては嬉しい改善だと思います。

例えば、無線 LAN と有線 LAN を切り替えた場合や、スリープして移動し別のネットワークに接続した場合など、これまでは IP Messenger を一度終了して起動しなおさないと相手にメッセージが届かなかったり、自分が二人表示されてしまったりしていました。他にも、起動したままスリープして時間が経ってからスリープ解除すると、ユーザ一覧が変わっているのに更新されていないので送っても送信に失敗するようなこともありました。

0.9.2 からはネットワークの状況が変わるとユーザ一覧を更新するので、社内や校内をよく移動する方でも、一日中 IP Messenger を起動しておくことができると思います。

技術的な側面から説明すると、BSDソケットとioctl システムコールを用いて UNIX 的な方法でネットワークの情報を取得していたのをやめ、SysmtemConfiguration.framework を利用して取得、更新の検出をするようにしたことで実現したものです。OS X 10.0〜10.2 でそのへんが整備されていないころ作ったものをこれまで引きずっていましたが、前回リリースで 10.3 以下をサポートしなくなったこともあり思い切って作り直しました。

• SystemConfiguration.framework でネットワークの情報を得る
• SystemConfiguration.framework でネットワークの変化を知る

安定性の向上。

ここ数ヶ月この件で何人もの方にご協力頂きました。ありがとうございました。

以前から突然落ちる、気がついたら落ちていたということがありましたが、解決できていませんでした。

0.9.1 以降、起動時に虹色のカーソルになって利用できないという報告がいくつかあり、クラッシュレポートやプロセスサンプル（デバッグ用の情報です）を提供して頂くなどして、調査しました。

私自身の環境では再現したことがなく（頑張っても出来ず）、直接原因のクラッシュ箇所を暫定対処してベータテストなどお願いするなど手探りの作業が続き、根本原因はなかなかつかめずに長期化してしまいましたが、結局のところ複合的な理由だったようです。

一つは文字列変換。SJIS と Unicode の変換でバックスラッシュと円記号を、日本語環境の場合には差し替えるような処理を入れていると不安定になります。その理由が確認できていないのですが、実際にその処理をやめると安定しますので、今回は機能を外すことで対処しました。

もう一つは同期制御（排他制御）という、マルチスレッドプログラミングでは基本的な部分でした。IP Mesesnger はいくつかのスレッドを内部で起こしているのですが、ユーザ一覧を管理している部分で、マルチスレッド対応が出来ていない部分があり、メッセージ受信や添付ファイルの送信などのタイミングでまずいことになる可能性がありました（そして実際なっていたんだと思います）。

その他や今後。

その他には、ソースをきれいにしました。非推奨の旧 API の利用を新 API に変えたり、 Xcode や Interface Builder の最低バージョンを上げるなど、10.5 SDK や 10.6 SDK でビルドしたときに警告が山盛り出てくるようなことはなくなりました。

今後の作戦についてはまた別エントリで考えをまとめますが、やりたいことや要望頂いていることはたくさんあるので、進めます。

最後に、0.9.2 で不具合等お気づきのことがありましたら、不具合報告フォームより連絡頂けると助かります。

少し前に書いていた問題が修正できたので報告。報告していた内容と少し理由が違い、Mac OS X に限らない通常のソケットプログラミングの問題でした。報告していたとおり、起動時の IP アドレスを記憶したままでユーザ管理をしていたことが問題でした。

「自分自身が二人表示されてしまう」という現象が発生するのは、無線 LAN で接続された状態で起動した状態から、有線 LAN を接続した場合です。
無線 → 有線の順であれば、有線接続時に無線 LAN 側が切断されていたもいなくても、同じように現象は発生するようです。
現象発生後、有線 LAN を切断すれば一人に戻ります。

また、状況とタイミングによっては、他の PC / Mac の IP Messenger にも二人に見える可能性があります。

原因。

IP Messenger は、通信に UDP/IP のパケットを利用します。

UDP パケットを受信するためには、ソケットがサーバとして受信待ちをして待機しておく必要があり、プログラミング上は bind() システムコールで、ソケットに IP アドレスとポート番号を設定します。このへんの作法は、C 言語であれば、UNIX でも Linux でも Mac OS X でも Windows でも同じ API を使用します。

これまでの実装では、サーバソケットに bind する IP アドレスを INADDR_ANY ( 0.0.0.0 ) という特別な値（マシンのすべての IP アドレスの該当ポート番号宛パケットを受信する）に設定していました。メッセージは送信、受信ともこのソケットを利用します。送信時は、その時点で一番優先されるネットワークの IP アドレスで送信され、受信時は全てのネットワーク（今回の場合なら有線 LAN と無線 LAN 両方）のパケットを受信します。

bind sokcet（エラー処理省略）

int 			sockUDP;
struct sockaddr_in	addr;
short			portNo = 2425;
 
sockUDP = socket(AF_INET, SOCK_DGRAM, 0);
 
memset(&addr, 0, sizeof(addr));
addr.sin_family		= AF_INET;
addr.sin_addr.s_addr	= htonl(INADDR_ANY);
addr.sin_port		= htons(portNo);
 
bind(sockUDP, (struct sockaddr*)&addr, sizeof(addr));

IP Messenger のユーザ自動認識の仕組みは、以下の方法によって実現されています。

1. 起動直後またはユーザリストを更新する IP Messenger クライアントは、ブロードキャストアドレスへの UDP パケットの送信により、LAN のサブネット内のすべてのアドレスに ENTRY パケットを送信する。
2. ENTRY パケットを（サーバソケットで）受信した他の IP Messenger クライアントは、受信者のユーザ情報を添えて ENTRY 応答を返す。
3. ENTRY 応答を受けた ENTRY 送信元は、応答を受信するごとにユーザリストにユーザを追加する。

最初の ENTRY はすべてのアドレスに送信され、同じポート番号で起動している IP Messenger クライアントにのみ届き、それぞれに応答を返してきます。それらをすべて集めると、ユーザリストができるというわけです。
起動済みで応答を返してくれた他の IP Messenger クライアントは、既に同じ事を実施してユーザリストを持っていますので、受信した ENTRY パケットの情報をもとにユーザを 1 名追加すれば、新たな参加者と同じ最新のリストになります。

今回の問題は、サーバソケットから無線 LAN と有線 LAN の両方の ENTRY パケットを受信してしまい、それぞれに ENTRY 応答を返すことにより発生します。異なるアドレスから受信した ENTRY 応答を別々のユーザとして扱うのは、IP Messenger のプロトコル上は正しい挙動です。つまり、応答を受けた側が二人表示するのは正しく、1 台の Mac なのに異なる IP アドレスで複数の応答を返してしまう部分がイクナイ
起動時やリスト更新時に、ユーザリストに自分が現れないケースを回避するため、起動時に作成した自分自身のユーザ情報をリストに強制的に追加してしまっていたことにより発生していました。
INADDR_ANY に bind されたソケットを利用していますので、有線無線の両方のネットワークでパケットを受信しても、返す応答はその時点で優先（有線ではなく…）されるネットワークの IP を使って送信されます。つまり、同じ IP アドレスで 2 通返ってしまうだけのことです。同じ IP アドレスで同じユーザであれば、ユーザリストに追加されるのは 1 人です。
自分が現れないケースの原因はわからないまま遙か昔に暫定対処したものでしたが、その強制追加ユーザと、ネットワーク環境が変わって異なる IP アドレスから送られたユーザが別のユーザとしてリストに表示されていました。

修正は、有線 LAN と無線 LAN が両方接続されて二つの IP アドレスを持っていても、どちらかの IP アドレス宛のパケットにだけ応答を返すようにするべきです。

ソケットプログラミングといえばなんといってもこれ、白本。基本です。IP Messenger 作り始める時にも結構お世話になりました（私のは第1版の古いやつですけど…）。

修正方法。

サーバソケットの bind アドレスを INADDR_ANY から自分の IP アドレスにすれば、この問題は解決します。
起動時やユーザリスト更新時に、起動時点の情報で用意した自分自身を追加することをやめれば、この問題は解決します。ソケットは INADDR_ANY に bind したままで問題ありませんでした

。

しかし、課題がひとつ。従来の実装では、bind 済みのソケットから接続されている IP アドレスを得ていたので、bind 前には IP アドレスがわからない、というニワトリ卵問題がありました。IP アドレスを得てからソケットを作りなおして bind しなおす等の方法がないわけではありませんが、もっと別の（スマートな）方法できちんと解決したいところです。

そこで、それとは別に、IP アドレスの取得方法を変えました。いままでは ioctrl という UNIX システムコールにより IP アドレスを得ていましたが、SystemConfiguration.Framework という Mac OS X 独自の方法を利用して取得する方式に変更しました。
SystemConfiguration.Framework を用いることで bind 前に IP アドレスを得ることができるようになり、起動時点で最も優先されている IP アドレス（システム環境設定のネットワークの設定で一番上にあるネットワークの IP アドレス）にのみ bind するようになりました。
今回利用している SystemConfiguration.Framework の仕組みは、Mac OS X 10.3 から導入されたものが含まれており、以前の開発時点では存在しなかった仕組みです（と軽くイイワケｗ）。SystemConfiguration.Framework の使い方については、また別のエントリで紹介したいと思っています。

v0.9.2。

今回の修正内容は、v0.9.2 リリースに含まれる予定です。

SystemConfiguration.Framework を利用することにより、有線 LAN と 無線 LAN の切替や、ネットワークの消失と復帰なども把握できるようになり、より IP Messenger を（ネットワーク接続環境が変わっても）シームレスに利用出来るようになりますが、その修正には内部構造の少々まとまった変更が必要になり、現在作業中です。

それらの修正と合わせて、近いうちに v0.9.2 をリリースしたいと思っています。
リリースに向けた状況はこちら。

http://bts.ishwt.net/roadmap_page.php

十分な移行期間は取ってきたつもりです。どうでもいいっちゃどうでもいい話ですが、記録的な意味でちょっと書いておきます。

WAKWAK でした。

旧サイトは、NTT-ME の運営する WAKWAK インターネットのものでした。どうしてかというと、引っ越したマンションの ISP が WAKWAK だったというだけの理由です。ホームページスペースもあったので、そこで公開を始めました。

入居した当初は WAKWAK 一択だったのですが、名前とはうらはらにいくつか不満点もあったため、その後他のプロバイダも使えるようになったタイミングで乗り換えました。しかし、IP Messenger 本家のサイトからリンクされていたり、乗り換えた時点では開発をアクティブにやっていなかったこともあって、従量課金ダイアルアップの最低限金額プラン（メールアドレスと HP スペースを維持するだけの月額数百円のプランです）に切り替えて、これまで維持（＝放置）してきました。

サイト移転。

で、本サイトを立ち上げてしばらく経ったところで IP Messenger の開発を再開することにしたので公開サイトをこちらに移転、WAKWAK のサイトは閉鎖することを決めました。

その際、突然閉鎖はどうかと思ったので、何ヶ月かは移行期間を取ることにしました。

アクセスカウンタ観測。

公開サイトをこちらに移転した時点から、旧サイトのアクセスカウンタを毎日記録するようにして、経過を見てみました。できればまるでアクセスされなくなってから閉鎖するのが理想です。

まずは、以前から利用していたアクセスカウンタを利用して観測。正確なユニークビジターでも、ページビューでもない、というものですがアクセス頻度の変化の把握は可能かと思います。これを毎日 0 時過ぎにカウンタ値を記録してグラフ化したものが以下です。青が累計カウント、オレンジが一日あたりのカウンタ増分です。

移転した 9 月 14 日以降、しばらく数十のアクセスが毎日続きますが、11 月に入ってアクセスは激減しています。

この減少には明らかな理由があります。Google からのインデックス削除と、IP Messenger 本家からのリンク変更です。

参照元確認。

当初、カウンタの目に見える減少を期待していたのですが、2 週間経っても変化が見られないので、10 月 1 日から Google Analytics と Google ウェブマスターツール による解析も開始しました。

実際トラフィックはどこから来ているのかを確認したところ、IP Messenger 本家と Google の検索結果からがほとんどでした。

つまり、 ipmsg.org からのリンクを変更してもらい、Google の検索結果に出ないようになれば 3 / 4 のトラフィックが減らせることになります。

あとはノーリファラーが 14 % 超いるのが大物ですが、これはブラウザブックマークに登録されていたり、IP Messenger アプリのヘルプメニューからアクセスされているものと推測され、ある程度時間をかけて一定数が減らせるかどうか、というところです。

Google の検索結果に出ないようにする。

Google の検索結果に出ないようにするには、自前のドメインであれば robots.txt でクロールを拒否することで簡単に実現できるのですが、プロバイダのホームページスペースの場合は robots.txt を用意することができないので、Google ウェブマスターツールに登録して、インデックスの削除依頼を出します。

依頼して数日で、たしかにインデックスから削除され、クロール対象から外されるようになり、検索しても表示されることはなくなりました。

大物参照元サイトからのリンクを変更してもらう。

IP Messenger の本家サイトから Mac OS X 版のサイトとしてリンクしてもらっているのが旧サイトのままであったため、毎日数十のアクセスが ipmsg.org からあり、その数字がほぼそのままこのサイトに流れてきているようでした。

ということでこれは簡単、本家サイトの作者さんにメールでお願いして書き換えて頂きました。

仕上げ。

Google からの削除と本家リンクの変更により、アクセスは激減しました。最後にノーリファラー対策を少々実施です。

まずブックマークに登録されている人たちですが、これはどうしようもないですが、更新チェック（ブラウザによっては購読といったりしますね）をしている可能性があるので、移転先や廃止の告知を大きく書いた上で、しばしば更新をかける（タイムスタンプ変えるだけですが）ことをしました。それで気づいてブックマークを置き換えてもらえるかもしれません。

また、アプリのヘルプメニューについては、v0.9.1 および v0.9.0+ をリリースすることで、ジャンプできる URL を変えて起きました。新バージョンの存在を見つけてくれるような人なら、旧サイトがなくなってもなんら問題ないとは思うんですけどね…。

ということで 12 月中旬に WAKWAK に解約手続きをしまして、月末の今日をもって旧サイトはなくなる、という運びになりました。

おまけ。

トータル 15 万オーバーのアクセス（カウンタベースですが）を頂いた、直近 2,000 アクセス分だけですが Analytics 情報。

OS とブラウザ。激しく偏っております。

アクセス元。結構いろんなお国から。

問い合わせを頂いたので、同じことでお困りの方のために書いておきます。

IP Messenger for MacOS X v0.9.1 の修正履歴に、「Intel Mac でユーザリストに自分自身が二人表示されてしまう問題を修正」という項目があるのですが、依然として自分が二人表示されてしまう場合があります。原因は別のところにあり、修正に取り組んでいます。

現状の回避策は、発生に気づいたら IP Messenger を一度終了して起動し直してもらうしかありません。

修正済みの不具合。

0.9.1 で修正した問題は、以前 0.9.1b2 を出したときのエントリに細かく書いてあります。原因は CPU が変わることによる影響で、起動時から終了までずっと自分が二人表示され、一方には届きますが一方には無視されてしまうものです。

これについては考慮漏れといえる類のミスで、CPU の種類を問わず正しく動作することができる API をきちんと使っておらず、開発当時は PowerPC しかなかったために気づかなかったものです。

今でも時々発生する不具合。

いまでも環境によっては二人現れてしまう場合、もしくはいつの間にか二人になっている、二人だったものがまた一人に戻っているという現象が発生する場合があります。
表示されるメカニズムに共通する部分もあるのですが、Intel Mac かどうかは関係なく、直接の原因は 0.9.1 で修正した部分とは別のところにあります。

現象は無線 LANと有線 LANを両方使っている環境で発生します（もし、それ以外の環境でも同様の現象が発生する方がいらしたら、不具合報告フォームから教えて頂けると助かります）。

• 無線 LAN と有線 LAN 両方接続した状態で起動する
• 無線 LAN のみ接続中に起動して、あとから有線 LAN につなぐ（あるいは切り替える）
• 上記の逆（有線 LAN 起動から無線 LAN へ）

といった状況です。特にオフィスや研究室等で、自席で有線 LAN（速いから）を使い、自席以外へ移動する際には無線 LAN に切り替えて使う、という場合には日常的に発生してしまうと思います。

原因と対応方針。

原因は、自分自身に関する情報を、起動時だけに取得していて、最初に見つかった有効なネットワークインタフェースのものをずっと使い続けてしまうことにあります。

IP Messenger は随時ユーザの一覧を更新するようなメッセージを相互にやりとりしているのですが、起動したあとでネットワーク設定がかわると、起動時とは別の IP アドレスでユーザ情報を送受信してしまい、見た目自分と同じようにみえるのですが同名の別ユーザとしてふるまうようになってしまいます。

これを回避するためには、ネットワーク環境が変わったタイミングで、ユーザ一覧の更新に当たる処理を実行することになります。ただ、そのあたりの処理は、Mac OS X 10.1 や 10.2 のころに UNIX like（BSD） の仕組みを利用して作ったもので動作していて、Mac OS X のサービス（System Configuration Framwork）を利用したものに置き換える必要があるのですがそこそこ大がかりになりそうで、時間がかかっています。

この問題は、BTS （Bug Tracking System）上で、#15 および #16 として管理していて、他の問題とあわせて修正して 0.9.2 としてリリースしたいと考えています。