しばらくＭＭＯまがいのチャットソフト開発がお休みしていましたが、復活しました。
今後の方向性をいろいろ考えていて、大体のベクトルが決まったので再開した次第です。

まぁぶっちゃけて言えば、夢が広がりすぎていて、ちと手に負えなくなりつつあっったり、ちょっと飽きてて、しばらく間をあけてたらアイデアがいろいろ出てきて、中間目標がいろいろ出てきてモチベーションが復活したというのが本音です。
今日は、ユーザーの認証の部分を作った。
どうせＭＭＯまがいのチャットソフトを作るんだから、自己紹介やらその他自分の属性をサーバー側で管理させたいよねぇってことで、ログイン認証部分を作成した。
まずは、DirectPlayにおける認証の実装方法
DirectPlayでは、Server/Client形態をとった場合、以下の流れで処理が進む。

Client::Connect
Connect関数を通してサーバーに接続要求。このとき、サーバーに渡す情報をpvUserConnectDataとして渡しておく
Server::DPN_MSGID_INDICATE_CONNECT
このメッセージハンドラで認証。成功ならDPN_OK,接続拒否ならそれ以外を返す。
ClientのConnect関数で渡されたUserDataがpvUserConnectDataとして取り出せるので、こいつを使って認証。結果をpvReplyDataにつめる。pvReplyDataのメモリは勝手に解放しちゃいけないので、メモリ確保した識別子をpvReplyContextにつめておく。
Client::DPN_MSGID_CONNECT_COMPLETE
認証が終了するとこのメッセージが取れる。Serverで渡した、pvReplyDataはpvApplicationReplyDataとして取り出せる。
Server::DPN_MSGID_RETURN_BUFFER
先のpvReplyDataのメモリの解放の許可が出るとこのメッセージが取れる。pvReplyContextを使ってメモリ確保した識別子からメモリを解放する。

非常にややこしい。こうやって整理して書けばすっきりするんだけど、最初は？？？だった。オンラインヘルプの英語版日本語版をつき合わせて、いくつかテストコードを書いてここまでたどり着いた。なんかその手の図がドキュメントについてると便利だったんだけどな。
あんまり自信が無いのであんまり参考にしないでください。ちゃんとドキュメントを見てね。
とりあえず、認証する流れは終了。
次に認証するための情報を格納しておくDBの確保。
毎度のことながら、最初はMSAccessで実験。MSAccessなら将来MSDEに持って行きやすいし。
ちょいちょいとテーブルを作って、サンプルデータを手入力。
次にMSAccessにアクセスするためのADO関連のコーディング。
せっかくなので、クラスライブラリ化。といっても、以前留守番ロボットを作ったときにC#で作ってあるので、デザインはそのまま。
が、
C++からADOにアクセスするのに、またもやつまづいた。
なんでいっつも引っかかるんでしょうねぇ。
CComBSTRと_bstr_tとWCHARとをまぜこぜにすると、どうもADOの調子が悪いようである。というか僕がまぜこぜにしてたのがいけないのだが。。。
特に、今回はWTLとATLを使っていて、MFCを入れていないので、余計に、CStringがややこしくなっていて、文字列関連は混乱しがちである。
WTLのCStringとATLのCStringがどうも混乱しているようである。リンクのときに気がついて頭の中に？？？となる。
試行錯誤の末、DBのアクセス終了。無事にDB内の情報を取り出せた。
これを元に認証。結果を返す。
次は、ユーザーの作成、プロファイルの表示、変更部分かな。