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