なうろーでいんぐ
キーボード↑↓
でもいいぞ
旧サイト形式へ帰りたい人
FTP理解。
2011年04月06日13時45分
ホストと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時間程度進める。
ファイル 362-1.png
銃面倒なのと良く分からん部分があるが、
まぁそれなりに見ながら真似してるわ。
記事カテゴリ:プログラム関連
徐々に進むプロトコル理解
2011年04月05日15時23分
HTTPでのTCP受信ができた後、SMTPを見る。
以前本で読んだ事もあって、理解が早かった。
添付データについては、multipart定義で大方
--Boundaryによりデータが分けられているのも、
既知でなんか個人的に嬉しかった。

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


4月6日 1:32
文字コードはこれだから嫌いである。
調べても情報が散っていて、収束させるのが面倒。
何とか解析終えた。
ファイル 361-1.png
エスケープ制御はチンプンカンプンだったので
激しく労力を割いた・・・とりあえずSMTP終了や。
POP3も読んでみたが、MD5(ハッシュ関数)で
取得したユーザー名、パス、タイムスタンプを変換し、
認証に使用してる点を理解すれば、
メッセージの処理が面倒なだけでそこまで難しいとは
思わなかった。更に次はTELNETだが、俺は未だに
この有用性が理解できてないので、ちょっと
これから軽く調べてみる。

同日 1:58
で、TELNETについて調べてみたんだが、かなり
問題を抱えている模様、後、ネゴシエーションが
相当面倒な事になってる。
windowsだと特に制御が複雑で、そもそも今は
SSHの方がリモート操作は主流なので、
横好きでない限りは勉強するのをおススメしない。
ざっと見てやり取りが単純作業に近かったので、
飛ばして次のFTPを見てみるとしよう。
記事カテゴリ:プログラム関連
クライアントサーバーシステム勉強中
2011年04月04日18時33分
昨日は急遽先輩の家で鍋をしてしまいました…。

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

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

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


同日 19:36
WAVEOUTハンドルを2つ用意して、
別個のデータとヘッダをそれぞれ登録し、
スレッドで同時に再生してみた所、
Sleepは必要だったが、同時に再生した。
DirectSoundではこれはミキシングされて結果を
出す方法もあるらしい。何にせよ、直に二つの音が
同時に出る事を確認できた。
あとの問題は必要分の動的管理だけ・・・。
先程の件は、DirectSoundのセカンダリバッファに
ついて調査する事で進行中。
分かったのは、やはりCreateFileもDirectSoundの
セカンダリバッファもこれから再生すべきファイルの
先頭場所をキューで格納して軽量化してるという点。
つまりCreateFile自体はファイルオープン同様
これから開くべきアドレスをハンドラとして渡し、
用が済んだら速やかにcloseする必要があるだけで
バッファからの読み込み位置だけを注視すれば
ダブルバッファリングの実装自体は難しく無さそう。
複数同時再生も先程試したので、効果音のバッファと
BGMのダブルバッファを別管理すれば、
特に音に関して困る要素は無くなった予感。
実装して結果を見ないと後は何とも言えないが。
記事カテゴリ:プログラム関連
アイテムの構想と次の勉強
2011年04月03日02時21分
ブロックを破壊した時にアイテムオブジェクトを
生成するのは、さほど難しくないとぼんやり考えた。
バーを長くしたり、ボールの速度を上げたり、
定石は用意してもいいかもしれん、
それまたフラグで出現管理できたらいいだろうし。
(最初から要らないと言われる人も居るだろうが;)
面白い挙動と言えばなんだろう、ボールの動き関連
マウストラックロールとか、爆発とか色々あるけど。

それはそうと、次の勉強。ネットワーク関連に
進もうと思う。ブロック崩しとは無縁に思うが、
だからこそ発見できる何かがあるやもしれん。
あと個人的に勉強したい事山盛りなので。
とりあえずそんな感じでまずはソケットでの
サーバークライアント通信からC++でやってみるか。


同日 14:18
コンソールでメール送信起動。
ファイル 359-1.png
サイト右上にもあるhi-hoのサーバーを使用。
パスワードは念の為権限の無い物で一度試してみる。
名前はBASE64で上手く通った。
画面は失敗しているが、おそらくpassが通れば
必然的に通りそう。
ある程度は理解しているが、解読が大変そうである;

もっとも、メーラーやブラウザの起動は
ShellExecute関数で簡略化はできそうだが;

急遽BGMでやり忘れてた事を思い出したwww
ストリーミング再生してねぇw
効果音ならメモリに置いて再生でもいざ知らず、
まさかメモリにBGM全置きするわけにはいかん;
慌てて調べなおすのであったorz
記事カテゴリ:プログラム関連