ぼちぼち片付けてたら、こんな時間に・・・。
今からまたプログラム解析ちょこっとやるわ。


同日　20:04
ブラウザからのページ閲覧の仕組みを理解。
結局コンソールと挙動は余り変わらず、
ブラウザが命令をsendしてそこから
サーバーが応答した内容をrecvするので、
情報に応じてページが表示できる。
インターネットの中身を垣間見た感じでした。
cgiとの接続も載ってるっぽいので、
そこも詳しく見ていこうと思いますわ。

クライアントの要求をrecvして解析してsendする、
その一連の流れは頭の中にかなりはっきりとした
イメージを作る事ができましたとさ。


同日 23:03
cgiとの連携プレイについては、
パイプ処理によってR/Wのパイプを形成し、
しかるべき設定値をしかるべき値にセットして
execve関数でcgiと連携してた。
膨大な環境変数は、流石他のプロセスと
言わざるを得ない。

ホストとFTPでconnectする所まではほぼ変わらず。
今回の場合は接続後、USER、PASS、TYPEを
sendして、PORTかPASVかで処理を分けていたが、
どちらもホストの情報からIPアドレスを割り出して
sendし、RETRコマンドをpath情報と共にsendすると、
結果をrecvできるという形だった。


FTPの通信ポートと、ファイル送信用のポートを別々に
用意する必要があり、サンプルのコードでは、
ホスト情報から送信用IPアドレスを割り出して
クライアント側から指定し、acceptを待つのがPORT、
サーバー側に依頼してconnectするのがPASVだった。


IPアドレス関連関数でちょっと迷ったのは、
inet_addr　:　アドレス→生IPデータ
inet_ntoa　:　生IPデータ→アドレス
といったアドレス関連関数や、
ntohs　:　バイトオーダーをプロセッサに応じて変更
といったエンディアンの指定だった。


次はいよいよ、WEBサーバーに入る。
例に漏れず非常に長いサンプルになってる;
分割してちょくちょく手を出すしかなさげだが…。

ネットワーク機能を如何にして利用するか、
そこが問題だな。

4月7日　2:19
突発的に3時間程度進める。

銃面倒なのと良く分からん部分があるが、
まぁそれなりに見ながら真似してるわ。

HTTPでのTCP受信ができた後、SMTPを見る。
以前本で読んだ事もあって、理解が早かった。
添付データについては、multipart定義で大方
--Boundaryによりデータが分けられているのも、
既知でなんか個人的に嬉しかった。

今回新たに分かったのは、MIMEエンコードの利点。
Base64であれQuoted-Printableであれ、
メールではデータを送る際に8bitから7bitに
落とし込む事が多い。主には文字コードに左右されず
データを送信先で保持する為だが、
これに加えてパリティビット等の誤り検出の1bitを
追加するのに非常に適しているのである。
・・・なんとまぁ便利な。
文字コードはEUC→JISが丁寧に説明されてたので、
頭が働いてる時に理解しようと思う。
コード見ただけで泥作業とわかるあれはｗｗｗ
先にPOP3プロトコルについてを読むかな。


4月6日　1:32
文字コードはこれだから嫌いである。
調べても情報が散っていて、収束させるのが面倒。
何とか解析終えた。

エスケープ制御はチンプンカンプンだったので
激しく労力を割いた・・・とりあえずSMTP終了や。
POP3も読んでみたが、MD5（ハッシュ関数）で
取得したユーザー名、パス、タイムスタンプを変換し、
認証に使用してる点を理解すれば、
メッセージの処理が面倒なだけでそこまで難しいとは
思わなかった。更に次はTELNETだが、俺は未だに
この有用性が理解できてないので、ちょっと
これから軽く調べてみる。

同日 1:58
で、TELNETについて調べてみたんだが、かなり
問題を抱えている模様、後、ネゴシエーションが
相当面倒な事になってる。
windowsだと特に制御が複雑で、そもそも今は
SSHの方がリモート操作は主流なので、
横好きでない限りは勉強するのをおススメしない。
ざっと見てやり取りが単純作業に近かったので、
飛ばして次のFTPを見てみるとしよう。

昨日は急遽先輩の家で鍋をしてしまいました…。

TCP/IPの基礎の基礎から勉強中。
先日はメールを簡易的に送信するプログラムだったが、
本格的にwinsockを勉強となると資料が膨大な範囲
なのでゆっくりと読み進めてます。

一方先日のストリーミング再生は、こちらを参考に
その３ Oggファイルでストリーム再生
http://marupeke296.com/OGG_No3_Stream.html
これまた読解中。
マルチバッファ自体は、2つの波形データとヘッダを
用意するだけで実現できたが、スレッド動作で
任意にバッファを切り替えつつ読み込みをさせるとなるともうちょっと詳しくやらねばならぬ。
それも後半に載ってるので後は理解だけ。

ストリーム再生において、CreateFileの戻り値が
HANDLE型（VOID*)という事は、
無理矢理すればReadするメモリの場所を移動可能か？
バッファサイズ分だけメモリに保持して残りを
引き出さなきゃならんと考えているが、ファイルから
引き出すオーバーヘッドがどうも気になって調べた。
取得位置を保持していれば読み込みの最適化に
利用できないかなぁと思うものの、
パスからCreateしてるし微妙なヨカンはしつつ。
…もうちょっと考えてみるとしよう。


同日　19:36
WAVEOUTハンドルを２つ用意して、
別個のデータとヘッダをそれぞれ登録し、
スレッドで同時に再生してみた所、
Sleepは必要だったが、同時に再生した。
DirectSoundではこれはミキシングされて結果を
出す方法もあるらしい。何にせよ、直に二つの音が
同時に出る事を確認できた。
あとの問題は必要分の動的管理だけ・・・。
先程の件は、DirectSoundのセカンダリバッファに
ついて調査する事で進行中。
分かったのは、やはりCreateFileもDirectSoundの
セカンダリバッファもこれから再生すべきファイルの
先頭場所をキューで格納して軽量化してるという点。
つまりCreateFile自体はファイルオープン同様
これから開くべきアドレスをハンドラとして渡し、
用が済んだら速やかにcloseする必要があるだけで
バッファからの読み込み位置だけを注視すれば
ダブルバッファリングの実装自体は難しく無さそう。
複数同時再生も先程試したので、効果音のバッファと
BGMのダブルバッファを別管理すれば、
特に音に関して困る要素は無くなった予感。
実装して結果を見ないと後は何とも言えないが。