2007/5/24

jabberd 2 でブロードキャスト  インスタント・メッセンジャー

まず /usr/local/etc/jabberd/sm.xml 中の <acl type='broadcast'> な部分のコメントアウトを外し、ブロードキャストできるユーザー ID をセットする。↓

<-- These JIDs can send broadcast messages (announce, motd) -->
<acl type='broadcast'>
<jid>xxxx@yyyy.zzz</jid>
</acl>

そして jabberd の再起動。

さて実際のブロードキャスト。クライアントから全てのユーザーにメッセージを送信するなら、xxxx@yyyy.zzz から yyyy.zzz/announce にメッセージを送る。
オンラインのユーザーに対してのみならば、yyyy.zzz/announce/online にメッセージを送る。

loudmouth の examples についてくる lm-send-async を使用する場合はこんな感じ。

lm-send-async -s yyyy.zzz -u xxxx@yyyy.zzz -p ??? -r test -R yyyy.zzz/announce/online -m "Broadcast test"
0

2007/1/12

MSN Messenger Protocol - SBP  インスタント・メッセンジャー

<MSN Messenger Protocol Version 11 (MSNP11) で仲間の表示名(ニックネーム)を変更する。>

SBP trid Contact's_CID MFN New_nickname\r\n

trid: メッセージ ID、で通し番号
Contact's_CID: 仲間の CID。LST メッセージと共に送られて来る C=xxx の xxx の部分
New_nickname: 新しい表示名(ニックネーム)。MSN 用に URL エンコードする必要がある

例)
新しい表示名が "Ahoaho Man" の場合は
SBP 34 83137-dc16-473b-aa83-95728db0cc07 MFN Ahoaho%20Man\r\n

>>>
>>>
>>>

<Changing a contact's nickname in MSN Messenger Protocol Version 11 (MSNP11) .>

SBP trid Contact's_CID MFN New_nickname\r\n

trid: A message ID
Contact's_CID: Contact's CID sent with an LST message (C=xxx: xxx is it)
New_nickname: A URL encoded new nickname

Example:
If a new nickname is "Ahoaho Man"
SBP 34 83137-dc16-473b-aa83-95728db0cc07 MFN Ahoaho%20Man\r\n
0

2006/10/25

MSN Messenger プロトコル  インスタント・メッセンジャー

今 MSN Messenger のプロトコルを調査中。
ふむふむ、何か XML とかそういう感じじゃなくて、一行ずつメッセージが送られてくる感じなんやな。
で、調査していくうちに分かったんやけど、MSN Messanger って、一つのメンバーを複数のグループに所属させることができるんやね。まじっすか。
普通、グループ : メンバーって 1 : N ちゃうん。MSN は N : N なんすか…。ああ、ほんま結構プログラム書き直しや。_| ̄|◯
かんべんしてけれ〜。
0

2006/10/14

loudmouth-1.1.2-xmpp を流す  インスタント・メッセンジャー

今日、loudmouth のメーリングリストに loudmouth-1.1.2-xmpp を流した。
すると「メッセージのサイズが大き過ぎるため、管理者がメールをチェックする必要があります。」とか何とかのメッセージが返ってきた。がーん。まあええわ。
今度はちょっくら MSN のプロトコルの方を調べますかな…。
0

2006/10/11

loudmouth と libjingle の SSL 対応(Windows) - 訂正  インスタント・メッセンジャー

以前の「loudmouth と libjingle の SSL 対応(Windows)」の所で「決して Crypt32.dll は使ってはいけない。」と書いたけど、間違いでした。

なんか libjingle は Crypt32.dll も使っているようですね…。って、何か依存関係をきっちり調べてないからよう分からん…。やっぱちゃんと調べるかな。でもまあ動いているからまあいいか。libjingle だけはちゃんとしたマニュアルが欲しいっすよ。
0

2006/10/6


ふう、一応 Jabber (XMPP) プロトコルの機能は一通り終了。
さて、loudmouth は本来古い Jabber プロトコルしか喋らないが、これを XMPP-1.0(おそらく)に対応したものを作った。これをそろそろ loudmouth 本家のメーリングリストに流そうかと思っている。まあ要るのか要らんのかわからんけど…。

さて、次の仕事が待っている。今度はぜんぜん違う種類。
0

2006/10/3

loudmouth と libjingle の SSL 対応(Windows)  インスタント・メッセンジャー

FreeBSD では loudmouth と libjingle の SSL 対応は素直にいった。しかし Windows ではつまずいた。

とりあえず openssl-0.9.8d をダウンロードして INSTALL.W32 の通りにインストール。次に loudmouth。これは問題なかったかな?(忘れた)そして libjingle。まず FEATURE_ENABLE_SSL と SSL_USE_OPENSSL を define する。(loudmouth が OpenSSL を使うので、Windows の Crypt32.dll は使わない。使うと本当にややこしいことになる。)←間違いでした…。

おっとその前に、FreeBSD でもそうだったけど libjingle の talk/base/openssladapter.cc の BIO_s_socket() を _BIO_s_socket() に名前変更。あと BIO_new_socket() も _BIO_new_socket() に変更。何かコンパイルの仕方で変更できるんだろうけど、こうしないと SSL の中にある同名の関数と衝突してしまい、うまく動かない。どうして libjingle が同じ名前の関数を使っているのかは分からない。もしかしたら理由があるのかも知れない。

そして最後に Windows の方で自分のソフトをコンパイルする時は、libeay32.lib と ssleay32.lib をリンク。決して Crypt32.lib をリンクしてはいけない。←Crypt32.lib もリンクしてました。

まあこれで何とか OK のよう。(毎回 Windows の時は骨が折れる。もう二度と Windows プログラミングはしたくないよー。)
0

2006/9/29


サーバーが Jabberd 2 ではなぜか JEP-0054: vcard-temp の仕様の通りに vCard をセットしようとしても、うまく行かない。 Jabberd 2 Installation and Administration Guide を見ると、FAX 番号や携帯の番号をセットする項目がない。(Figure 13.5.2. Jabberd Table Descriptions 参照)なので、少し違ったメッセージを送信してやらないといけない。

<iq type="set" id="msg_23">
<vCard xmlns="vcard-temp" version="2.0" prodid="-//HandGen//NONSGML vGen v1.0//EN">
<FN>フルネーム</FN>
<ORG>
<ORGNAME>会社名</ORGNAME>
<ORGUNIT>部署</ORGUNIT>
</ORG>
<TITLE>肩書</TITLE>
<TEL>
<WORK/>
<VOICE/>
<NUMBER>111-111-1111(電話番号)</NUMBER>
</TEL>
<EMAIL>
<INTERNET/>
<PREF/>
<USERID>bokuno@mail-address.com</USERID>
</EMAIL>
</vCard>
</iq>

てな感じで送ってやらなくてはいけない。(ん、FAX、携帯がないだけで正規のメッセージか?本当は <WORK/><VOICE/> や <INTERNET/><PREF/> はなくてもいい。)
FAX や携帯の番号がセットされないのはちと痛いが、しゃあないなあ。今回は Gaim ですらこれに対応していなかった。いち早くこっちが対応したということで。
ちなみに Jabberd 2 ではこういった情報は MySQL, PostgreSQL と言ったデータベースに保存される。(ID、パスワードも保存することができる)なかなかおもしろい。
0

2006/9/20

訂正 - mu-conference の設定 - クライアント  インスタント・メッセンジャー

う、プロトコル仕様書 JEP-0045 に乗っ取って送信メッセージを作っていたのに、なんとこれではうまくいっていないことが分かった。

9/16 分のメッセージの roomconfig_ のところを全部 owner_ に変えなくてはならない。正しくは

<iq type="set" to="aaa@conference.xxx.net" id="msg_30">
<query xmlns="">http://jabber.org/protocol/muc#owner">
<x type="submit" xmlns="jabber:x:data">
<field var="muc#owner_publicroom"><value>0</value></field>
<field var="muc#owner_passwordprotectedroom"><value>1</value></field>
<field var="muc#owner_roomsecret"> <value>xxx</value></field>
</x>
</query>
</iq>

これは Gaim のメッセージを見てわかった。たのむ、JEP-0045、いくら Draft(下書き段階)だからと言ってこういう大事な事は書いておいてくれ…。しかも間違ったメッセージ送ってもエラーを返さないし…。

そういや Jingle でも同じ事があったなあ。仕様書に書いてあるメッセージと全く違うメッセージを送らなあかんかったし。Google Talk は一体どうしているのか…。

これからは Gaim の出力だけを信じよう。 Gaim 作った人も大変だったろうなあ。
0

2006/9/16

mu-conference の設定 - クライアント  インスタント・メッセンジャー

ふう、やっと部屋に入ることができた。
クライアントは部屋を作る時、configuration メッセージを送らなければならない。

<iq type="set" to="aaa@conference.xxx.net" id="msg_30">
<query xmlns="">http://jabber.org/protocol/muc#owner">
<x type="submit" xmlns="jabber:x:data">
<field var="muc#roomconfig_publicroom"><value>0</value></field>
<field var="muc#roomconfig_passwordprotectedroom"><value>1</value></field>
<field var="muc#roomconfig_roomsecret"> <value>xxx</value></field>
</x>
</query>
</iq>

仕様に乗っ取り
roomconfig_publicroom -> 0: 検索に引っかからないよう
roomconfig_passwordprotectedroom -> 1: パスワードを必ず設定
roomconfig_roomsecre -> xxx: パスワード

ちょっとぐらい文法に誤りがあってもエラーを返してこないところが痛い。
まあこれで良しとしよう。

まあこれで Jabber 会議室 (mu-conference) に入ることができた。
0



teacup.ブログ “AutoPage”
AutoPage最新お知らせ