MSN Messenger Protocol その2

MSN Messenger のクライアントのエンジンを書いている。
無事に認証に成功した。パブリックプロファイルも取れた。


昨日、クライアントのticketがもらえることを確認したところで力尽きたので、そこからの続き。
クライアントのticketを受けて、それを使って、Notification Serverに認証の部分の追加。

エラー911

エラー911は認証失敗の意味。
なんですと?
考えること10分。
PassportのID間違えてるし。。。。
IDを正しく修正して、、、
無事に認証成功。
認証とともに、Messengerのハンドル名(表示名?)が取得できる。
が、
ハンドル名(表示名?)が文字化け。あり?ASCIIで通信しちゃだめですか?
考えること5分。
今まで、すべての通信をASCIIでやってたんだけど、UTF-8でやるように変更。
無事ハンドル名(表示名?)が正しく取得できました。
認証成功とともに、ユーザーのパブリックプロフィール(年齢とか性別とかのユーザーの公開情報)も正しく取得できました。
Passportってこうやって使うのね。Passportの流れがわかると、MSNのWebのURLの流れがちょっと理解できた気がした。
やってみたら、案外簡単じゃん。
まぁ参考にした、MSN Messenger Protocolというドキュメントがよくできてるからなんだろうけどね。
接続ができたことを確認したところで、接続の処理をひとつのクラスに整理。
調子に乗っているうちに、MSN Messenger Protocolを読み進める。
次は、状態の変更かなぁ。
読み進めるうちに、サーバーがPing(CHL)を打ってくることが判明。これをChallengeというらしい。
このChallengeに対しては、MD5でエンコードした文字列をPong(QRY)として返さなければ、接続が切られてしまうらしい。
今までいろいろMSN Messenger Protocolの実装のソースコードを読んだけど、そのソースコードのすべてにMD5って用語が出てきてたのよ。MD5だから、てっきりログイン認証のところで使うのかと思ってたのに、ぜんぜん出てこなかったから、あり?って思ってたんだけど、ここでMD5が必要なのね。
.NETのライブラリにMD5に関するクラスが存在することを確認。多分、大丈夫。
状態の変更や、メッセージの送信など、クライアント側からのリクエストは、同期通信で考えればOKだったんだけど、考えてみれば、サーバーからの送信もあるわけで、これらの処理に関して、ちょっとデータの受信部分を考えなきゃいけないことが発覚。
例えば、
状態の変更を連絡。クライアントは、その後、状態の変更の確認の受信を待つわけだが、状態変更確認の受信が来る前に、誰かからチャットの招待リクエストが来る。
みたいな、非同期における時差の影響で、予想外のデータを受けることも考えるわけで、そのあたり、データの受信部分の構造をちょっと考えたほうがよさそう。
これは宿題だな。
ふと思ったが、
僕が普段実際に使っているアカウントで、ログインのテストを繰り返していたわけだが、これって、僕を友達リストに加えてくれている人にしてみれば、「ぢはログインしたり落ちたりを何度も繰り返して、何やってるんだ?メッセージを送信しても返事が無いし。」と不振に思っているかもしれない。
友達リストに入っている人が、出たり入ったりすると、小さなウィンドウが出て知らせてくれるもんね。すんげぇうっとうしかったかも。
そのような状況を見かけた方。原因は上記の通りです。
実験用のアカウントを取ったほうがいいな。

コメントを残す