AFP, 画面共有の接続が遅くなった

M3CSLさん、どうもお世話になります。

今気づいたのですが、どうもこのログは毎回吐き出されている訳ではないようです。

それと、時間的に共有画面が開いた後のログになっていますので直接は関係ないように思います。（毎回でない点が気にはなりますが）

因に、使用しているマウスとキーボードについては、

クライアント：MackBookPro 15inchの内蔵キーボード、トラックパッド

サーバ；Mac mini + Apple純正USBキーボード（テンキー付）+ Wacom Intuos3タブレット

です。

#クライアント側に何もログが残ってないことから、画面共有アプリにはエラー認識はなくて何らかの条件で「60秒待て！」って動きをしてるんでしょうね。...はて、どうしたものか...もう悪あがきは止めて10.6.1を待ってみましょうか（笑）

こちらのディスカッションにも関係があるかもしれないですね。サーバ側の ARD 3.3 の仕業かもしれないです。

Remote Desktop 3.3 のバグ？

この件では、例によってディスプレイ関連のニオイがプンプンするわけですが（笑）、サーバ側のMac miniはどのような解像度で立ち上がっていますか？　例えば解像度を小さくしてみたらどうなるでしょうね。

私の所でもApple Remote Desktop Admin 3.3（クライアントは3.3.1）にアップデートしていますが、画面共有でなく、Remote Desktop.app からの接続の際にいったん通信が途切れ、再度接続しに行く挙動になりました（ルータ越えの場合）。接続にかかる時間は3.2の時とほとんど変わらないので、全く不都合はないのですけれど。

logの提供ありがとうございます。Firewallの記録から考えてもPajerow さんのお考えの通り、接続は出来ていると言う事ですね。

WindowServerのlogも毎回、記録されるわけではないのですよね。

OSX10.6側が何かの情報提供を、VNCサーバ側からくるのを待っているのだろうと思うのですが。(10.5.xの際には、確認しないような)

改善の兆しもなく提案ばかりで心苦しいのですが、画面共有.appの環境設定を変更しても変化無いでしょうか。

ARDのスレッド、読ませていただきました。

なるほど、ディスプレイまわりで関係が深そうですね。

私はARDは使ってませんが、ディスプレイは24インチと17インチのデュアル構成にしてますし...

アップデートに期待してしばらく様子見と致したいと思います。（遅いながらも一応繋がってますので）

画面共有.appの環境設定を変更しても変化無いでしょうか。

ひととうり試してみましたが、変化なしですね。

ただ、「フルサイズで表示」を選ぶと画面が真っ黒けになって使えませんでした。デュアルディスプレイ環境が関係してるかもしれないですね。

先のM3CSLさんへの返信にも書きましたが、ARD関係のバグもあるようですしアップデートで改善されるよう期待して待つことに致します。

貴重なアドバイス、どうもありがとうございました。

.

Pajerow さんによる書き込み:

ただ、「フルサイズで表示」を選ぶと画面が真っ黒けになって使えませんでした。デュアルディスプレイ環境が関係してるかもしれないですね。

私の所でも、この「真っ黒け」10.5.xでも10.6でもは発生いたしておりましたが、いつの間にやら改善しておりました。

Safeboot中でも、無線LANが使用できるMacもあるようですし、有線LANなら間違いなく繋がると思うので可能なら、Safeboot中は繋がるかどうか、確認してみては如何でしょうか。

.

denden さんによる書き込み:

サーバー側の /var/log/krb5kdc/kdc.log に以下のログメッセージが出力されました。

(中略)

Client not found in Kerberos database

OS X Serverのサポート資料を参考にkerberosのテーブル(だったか?)を再構築してみるとかどうでしょう。

クライアントとサーバにも搭載されているとは、10.5. xの際に聞いた覚え(違ったらごめんなさい^^;)がありますが、こんな支障が出るとは。

こんばんは

うちでも同じような状況です。

MacMini(10.6.1)　→　MacMini(10.6.1) にしても同様な状況ですが、

相手側のIPを手入力にて固定IPにして、クライアント側のHostsファイルに相手側ホスト名を追記したら速くなりました。

ターミナルから　sudo vi /private/etc/hosts　で編集します。

vi の使い方は自力で・・・・

E_I さんによる書き込み:

相手側のIPを手入力にて固定IPにして、クライアント側のHostsファイルに相手側ホスト名を追記したら速くなりました。

ターミナルから　sudo vi /private/etc/hosts　で編集します。

vi の使い方は自力で・・・・

こんばんは、Pajerowです。　当スレッドで「画面共有の接続に30秒60秒程の時間がかかる」旨のコメントを致しておりましたが、E_Iさんからご教示頂いた上記の方法で無事解決しましたので、ご報告させていただきます。

クライアントのhostsファイルにサーバのアドレスとホスト名を追記することで、「画面共有の接続が即時に完了する」ようになりました。

E_Iさん、ご教示ありがとうございました。

このメッセージは次により編集されています: Pajerow　誤記訂正しました

こんばんわ

他の方法で解決出来る事が判明しました。

DNSサーバをルータのIPにしていると遅くなるようです。

1.DNSサーバ指定をルータのIPアドレスからプロバイダのアドレスに手動にて変更する。

2.ルータからにプロバイダのIPアドレスをDNS通知させる。・・・できないルータもあります。（その場合は１）

以上です。

E_Iさん、こんばんは。　情報提供、大感謝！！です。

当方、お教示頂いた情報で二つの懸案事項が一気に解決致しました。（まさに一石二鳥でした）

E_I さんによる書き込み:

DNSサーバをルータのIPにしていると遅くなるようです。

1.DNSサーバ指定をルータのIPアドレスからプロバイダのアドレスに手動にて変更する。

2.ルータからにプロバイダのIPアドレスをDNS通知させる。・・・できないルータもあります。（その場合は１）

前者1.の方法を試したところ、

1. まず、本件である画面共有が即時に繋がるようになりました。（先にご教示いただいたhostsへの登録については削除しました）
2. また、当方で別途懸案事項であったRe: mailを使って送信が出来ません？？（メール送信はできるが完了までに時間がかかる）についても同時に解決致しました。

どうもありがとうございました。

＃詳しいことはわかりませんが、Snow Leopardになって名前解決の方法がどこか変わったんでしょうか？　OSのバグではないんですかね？　Leopardまではこんな事なかったんですけど...

どうもです。

tcpdumpでモニターしてみました。

画面共有起動後　数パケットのところでDNSサーバに接続相手IPの逆引きの問い合わせをしています。（何故かはわかりませんが・・・）

hostsファイルに登録の場合はこの問い合わせをしません。

（内部で解決しているためと思われます。）

プロバイダーのDNSの場合はそんなドメインは無い(NXDomain)と帰ってきます。

（プライベートIPなので当然です。）

DNSがルータのIPだとServFailが帰ってきます。

（逆引き機能が無いからと思われます。）

ServFailが帰ってきた場合は８回ほどリトライして駄目だと次の動作に入って接続します。

その間数十秒待ってます。

その後ユーザーとパスワード入れるダイアログが出でます。

遅い理由はこのためですが、何故逆引きの問い合わせをDNSにしているかが不明です。

画面共有とファイル共有と共通した動作なので認証の仕組みあたりが怪しいです。

失敗しても接続できるのだから意味ないと思われます。

以上ここまで解析してみました。

なるほど...

E_Iさん、詳しい解析情報の提供ありがとうございます。

私はWake on Demandが関係したSnow Leopardでの仕様変更（バグ？）ではないかと疑っているのですが...

DNSを外部に変更してから、

OS X server10.5.8でも同じ現象がでておりました。

なぜか認証に時間がかかっていたのですが、

サーバーのDNS設定をプロバイダーにしたら、

直りました。