仙石浩明CTO の日記

「jabber.jp が Google Talk と 相互接続できないのが某所で問題になっている。」 昨日、そんな声が社内から聞こえてきました。 jabber.jp というのは 2001年6月のサービス開始以来、 KLab で運用している jabber (通信に XMLプロトコル XMPP を使う、 インスタント メッセージング サービス) サーバです。 KLab 社内公式 IM (インスタント メッセンジャー) として大いに活用していますが、 社外のかたにも開放しています。

その時は、 「え？ Google ? あそこって他サイトとの相互接続ってやってなかったんでは？」 と、思わず答えてしまいましたが、 いつのまにか 相互接続を開始していたんですね。 知らなかった... orz
jabber.org などとは 相互接続できていたので、 Google Talk と接続できないのはアチラの問題、と思い込んでいました (_O_)。

多くの方々に利用して頂いている jabber.jp で調査を行なうよりは、 (落ちても誰も文句言わない ;) 自宅サイト gcd.org も Google Talk と接続できないという 問題をかかえていたので、gcd.org で調査を始めました。

通信できないときに最初にすべきことと言えば、 まずはパケットが届いているか調べることですね。 tcpdump でパケットダンプを取りつつ、 Google Talk (gmail.com) に jabber クライアントでログインして GCD (jabber.gcd.org) へチャットしてみました。

senri:/home/sengoku # tcpdump -i ppp0 port 5269
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
07:07:11.672591 IP iproxy.google.com.32489 > gcd.org.5269: S 2133894537:2133894537(0) win 5720 <mss 1430,sackOK,timestamp 379820136 0,nop,wscale 0>
07:07:13.004593 IP gcd.org.5269 > iproxy.google.com.32489: S 1097254147:1097254147(0) ack 2133894538 win 5608 <mss 1414,sackOK,timestamp 401538947 379820136,nop,wscale 2>
07:07:11.837330 IP iproxy.google.com.32489 > gcd.org.5269: . ack 1 win 5720 <nop,nop,timestamp 379820153 401538947>
07:07:11.837527 IP iproxy.google.com.32489 > gcd.org.5269: P 1:142(141) ack 1 win 5720 <nop,nop,timestamp 379820153 401538947>
07:07:11.837574 IP gcd.org.5269 > iproxy.google.com.32489: . ack 142 win 1670 <nop,nop,timestamp 401538988 379820153>
07:07:11.837762 IP gcd.org.5269 > iproxy.google.com.32489: P 1:187(186) ack 142 win 1670 <nop,nop,timestamp 401538988 379820153>
07:07:12.002559 IP iproxy.google.com.32489 > gcd.org.5269: . ack 187 win 5720 <nop,nop,timestamp 379820169 401538988>
07:07:12.003738 IP iproxy.google.com.32489 > gcd.org.5269: P 142:242(100) ack 187 win 5720 <nop,nop,timestamp 379820170 401538988>
07:07:12.046764 IP gcd.org.5269 > iproxy.google.com.32489: . ack 242 win 1670 <nop,nop,timestamp 401539040 379820170>
07:07:13.486820 IP gcd.org.41294 > 216.239.57.83.5269: S 1003009747:1003009747(0) win 5656 <mss 1414,sackOK,timestamp 401539400 0,nop,wscale 2>

最初 Google 側から GCD の 5269番ポートへ接続があって、 それに答えて GCD から Google へ dialback 接続を行なう... ところが、それに対する応答が無い。 実際、netstat で調べてみると SYN_SENT のままです。

senri:/home/sengoku # netstat -nap | grep s2s
tcp        0      0 0.0.0.0:5269            0.0.0.0:*               LISTEN      14525/s2s
tcp        0      1 60.32.85.216:41294      216.239.57.83:5269      SYN_SENT    14525/s2s
...

見るからに、216.239.57.83 へ接続を試みていることが間違いのようです。 216.239.57.83 というのは gmail.com の A レコードの一つですね。

senri:/home/sengoku % host gmail.com.
gmail.com has address 64.233.161.83
gmail.com has address 216.239.57.83	←コレ
gmail.com has address 64.233.171.83
gmail.com mail is handled by 50 gsmtp163.google.com.
gmail.com mail is handled by 50 gsmtp183.google.com.
gmail.com mail is handled by 5 gmail-smtp-in.l.google.com.
gmail.com mail is handled by 10 alt1.gmail-smtp-in.l.google.com.
gmail.com mail is handled by 10 alt2.gmail-smtp-in.l.google.com.

では、jabber サーバ間の通信では接続先をどのように探せばよいのだっけ、と 調べてみると、 SRV レコードに サーバのホスト名とポート番号を 登録しておくことになっているようです。 以前は A レコードを使っていたような気がするのですが、 A レコードを直接使ってしまうと、 jabber ID (JID) のドメイン名と jabber サーバのホスト名を一致させる必要があって 柔軟性を欠くから、 SRV レコードに変更したということなのでしょう。

私の自宅サイトのような小規模サイトなら jabber.gcd.org というホスト名で jabber サーバを立ち上げることはさほど問題ではありませんが、 Google のような大規模サイトだと、gmail.com というホスト名で jabber サーバを立ち上げてしまうと運用が面倒なことになりそうです。 gmail.com の SRV レコードを引いてみると、 xmpp-server.l.google.com という応答が返ってきました。 つまり (JID のドメイン名である) gmail.com とは 異なるサーバ xmpp-server.l.google.com で jabber サーバを動かしているということです。

senri:/home/sengoku % host -t srv _xmpp-server._tcp.gmail.com.
_xmpp-server._tcp.gmail.com has SRV record 5 0 5269 xmpp-server.l.google.com.
_xmpp-server._tcp.gmail.com has SRV record 20 0 5269 xmpp-server1.l.google.com.
_xmpp-server._tcp.gmail.com has SRV record 20 0 5269 xmpp-server2.l.google.com.
_xmpp-server._tcp.gmail.com has SRV record 20 0 5269 xmpp-server3.l.google.com.
_xmpp-server._tcp.gmail.com has SRV record 20 0 5269 xmpp-server4.l.google.com.
% host -t a xmpp-server.l.google.com.
xmpp-server.l.google.com has address 64.233.167.125

というわけで通信できない原因が分かったので、 あとは GCD の jabber サーバに SRV レコードを参照させればいいだけですが、 幸い現在使っている jabberd2 サーバは SRV レコードを参照する機能を持っていました。 なので設定ファイル resolver.xml に次の行を追加するだけです:

  <lookup>
    <srv>_xmpp-server._tcp</srv>
    <srv>_jabber._tcp</srv>
  </lookup>

また、SRV レコードを参照する jabber サーバ＆クライアントのために、 ネームサーバに SRV レコードを登録しておいたほうがいいでしょう。 GCD ではネームサーバとして djbdns を使っているので、 次の行を tinydns のレコードファイルに追加します:

:_jabber._tcp.jabber.gcd.org:33:\000\012\000\000\024\225\006jabber\003gcd\003org\000
:_xmpp-server._tcp.jabber.gcd.org:33:\000\012\000\000\024\225\006jabber\003gcd\003org\000
:_xmpp-client._tcp.jabber.gcd.org:33:\000\012\000\000\024\146\006jabber\003gcd\003org\000

以上の修正を行なった上で、 GCD と Google Talk それぞれに jabber クライアントでログインして、 チャットしてみると、あっさりつながりました。 続いて同様の修正を jabber.jp に対しても行ないました。

というわけで、約5ヶ月の間ご迷惑をおかけしましたが、 jabber.jp と Google Talk は、 ようやく本日より相互接続できるようになりました。

「断片的な知識と体系的な知識」にトラックバックを頂きました。 長久さま曰く:

体系的な知識を学ぶことはある程度可能です。 但し、その分野が十分に研究されていて、体系化されているならば、 という条件が付きます。体系化は、学問化と言っても良いでしょう。 この場合、本当に良くできた教科書を読むことで、 体系的な知識を学ぶことができます。
しかし、多くの分野では、体系化まで行ってません。 コンピュータ科学においても、体系化まで進んでいる分野は、一握りです。

「体系」を辞書で引くと、 「一定の原理で組織された知識の統一的全体」(広辞苑) とあります。 私は「統一的全体」として、 かなり広範囲の学問分野を想定していたのですが、 長久さまは「コンピュータ科学においても、体系化まで進んでいる分野は、 一握りです」と 表現されていることから、 もっと狭い個々の技術分野について考えられているのでしょう。 技術分野がどんどん細分化されていく昨今、 長久さまのように、 個々の技術分野の「体系」をイメージされるかたのほうが 多数派なのかも知れませんね。

私がイメージする「体系的知識」とは、 コンピュータ科学でいえば、 例えば「オートマトン理論」のような学問体系のことです。 現在のコンピュータは全てオートマトンですから、 コンピュータ科学全体が一つの体系と言ってしまってもいいかも知れません。 この意味でコンピュータ科学は、かなり体系化されています。 コンピュータ科学という「体系」の視点から見れば、 その中の個々の技術分野の「体系」は、 他の技術分野と相互に関連づけられていない限り 「断片的知識」と言いきってしまえるかも知れません。

「コンピュータ科学 体系」で Google 検索してみると、次の本が見つかりました:

図解雑学 コンピュータ科学の基礎 河村 一樹 (著)

内容
ほとんどの情報処理試験に出題され、 もっとも難しいジャンルとされる「コンピュータ科学基礎」について 図版を豊富に使って丁寧に解説。 コンピュータ科学がいかに体系化され、 いかに研究が進んでいるかを実感できる本。

目次
1 コンピュータサイエンスと符号化理論の基礎
2 論理学の基礎
3 集合論の基礎
4 形式言語理論の基礎
5 オートマトン理論の基礎
6 グラフ理論の基礎
7 プログラミング論の基礎

検索で見つけただけの本なので内容がどうなってるのか分かりませんが(^^;)、
この目次は、コンピュータ科学の体系を俯瞰するのに丁度いいと感じました。

オートマトン理論の中には、 チューリングマシンや計算量の理論などが含まれてくるでしょう。 非決定性チューリングマシンが多項式時間で解くことができる問題のクラス NPや、 オラクル付チューリングマシンが解くことができる問題のクラス階層は、 コンピュータ科学の体系の中でも最も重要な概念の一つと言っても いいかもしれません。

# オラクルといっても DBMS でもなければ、マトリックスの母でもありません ;-p

また、グラフ理論に関連する分野として、組み合わせ理論や探索などがあります。 遺伝的アルゴリズム(GA)は、確率的探索の中の一分野に過ぎません。 GA を単に、交叉・突然変異・自然淘汰からなる探索アルゴリズムとして 理解してしまうと、 本質を見失ってしまうのではないでしょうか。

プログラミング論には、 近年急速に発展しつつあるソフトウェア工学全体が含まれてきます。 秒進分歩といってもいいくらい新しい概念が次々と提案される分野ですが、 本質さえきちんと押えておけば、 数年で廃れる流行に振り回されずに済むのもまた事実です。

同ページで長久さま曰く:

「これ読めば、探索を体系的に学べます」というオチがきたら良かったと思います。 この終わり方だと、生殺しっぽいので。 でも、探索を体系的に記した本って、タブンないと思うんですよね。 捉えるレベルがメタ過ぎて、抽象的になっちゃうと思うので。

まずはコンピュータ科学全体を俯瞰し、 「論理学」「形式言語理論」「オートマトン理論」 「グラフ理論」「組み合わせ理論」「符号化理論」などの コンピュータ科学を支える重要理論を大ざっぱに把握した上で、 特に興味がある分野(例えば探索)をより突っ込んで勉強する、という方法が いいのではないかと思っています。 重要なのは、最初のうちは枝葉末節にあまり捕らわれないようにすることでしょう。 木を一本一本見ていて森が理解できるようになるほど、 コンピュータ科学という森は小さくありません。 まずは森全体の地図を見て体系を理解しておくことが重要でしょうね。

タイトルで言いたいことを言い尽くしてしまっている (^^;) のですが、 技術をウリにする会社は、 その立ち上げメンバに三種類の人種が含まれていることが必須なのだと思います。 すなわち、

1. 湯水のように新しい事業アイディアを思いつくアイディアマン
2. アイディアを実際の製品として実現する技術者
3. 完成した製品を売る戦略を立案し実行するマーケッタ

会社の立ち上げというと、 ともすると同じような人種が集まりがちです。 例えば、 技術出身者ばかりで立ち上げた会社や、 その逆にアイディアマンばかりで立ち上げた会社です。 前者は技術出身だけど営業のことをある程度知っている人が営業担当になり、 後者は技術者ではないけれど仲間内では技術に詳しいと一目置かれる人が 技術担当になったりします。

しかしいくら人当たりが良くても技術者は技術者ですから、 どうしても製品への思い入れが強くなってしまい、 肝心の売るための戦略がおろそかになって 場当たり的な営業になってしまいます。 また、ある程度会社の規模が大きくなってくると、 営業チームを作って組織的な営業が必要となりますが、 セールスパーソン一人一人の心を理解している人でなければ リーダシップをとることは難しそうです。 私自身は技術者ですから、 優秀なセールスパーソンは無条件に尊敬するものの、 どうすれば営業チームを育て、機能させていくことができるのか、 (いろいろ営業ハウツー本を読んで勉強したりはしているのですが ^^;) 根本的なところは理解の範囲外にあるような気がしています。

同様に、技術者でない人が技術者チームを率いようとしても、 技術者一人一人の技術力の差がどこにあるのか、 きちんと理解することは難しいでしょう。 たまたま優秀な技術者が運良く入社してきたとしても、 その人の真の実力を理解して評価することができなければ、 早晩その人はもっと評価される場、 あるいはもっと自身を磨ける場を求めて去ってしまうはずです。 優秀な技術者にとって一番の屈辱は、 レベルの低い技術者と同列に扱われることなのですから。 自分は技術者に対する尊敬の念を持っているから技術者がついてくる、 なんて言う人にかぎって、 ピンもキリもいっしょくたに「尊敬」したりするので、 余計にタチが悪かったりするものです。