69式のおっさんを呼び込むスレ【00000010b】

しかし深いなあ。。。

903はゲーム屋なのかな。
いやプロセッサマニアのようだな。

以下のキーワードでぐぐったらトップに出てきた。サンキュー
Windows スピンロック回数

ところで、このスレのタイトルにもなっている
69式って、69年生まれという意味？
だったら、俺は66式だなw。
昔はよくマ板やム板にいたけど、また戻ってきたw

フリーじゃなくてサラリーだけどよろしくね。
おっと、勤務時間中に2chなのは内緒だよ。

>おじゃばよ、インデントは大事だろ。
ってか、行頭半角スペースは見えないんで
ああいう風にインデントするには、半角スペースx2->全角に変換すればいいんだが。
結構面倒なんだけどね。じつは、おれも面倒。

>>916
組み込み屋さんです。

組み込みスレに行こうと思ったら、「おっさん」という単語にぐっときたんで。

>>903
よろしく。
ここでのおじゃばはみんなにカワイガラレながらもいじめられている
キャラクタなんだな。あいつはジャワ糞だけどなかなかいいやつだよ。
次スレは
66式(UNIX)69式(WIN)のおっさんたちを呼び込むスレ【00000011b】
になるな

ここでの主賓(?)の名を拝借して、この名前にするか。
でも、いつまでもここにいるかどうかわからんよ。

「おっさん」という単語に引かれてウォッチして話の波長があうところに
UNIXというかPOSIXがあったのでPOSIX系の話を長々としたけど、
本職は組み込みで私の業務経歴にUNIXなんて1つも出てきませんから。残念。

WindowsNT4.0のころのWindowsは出てくる。
Win32APIごりごりとかMFCでうにうにとか、ATLでCOMCOMとか、VBでぶびぶびとかから
デバドラも作っていたこともあるんで、なんか合う話があれば飛び込むかも。
最近は、すっかり開発ホストにしかつかってないね。この件については化石です。

ところで、VBな人は死滅してJavaな人に鞍替えしているの？昔はよくVB厨が多かったようなきがするけど。

ここの主賓は最近オパイパブ通いに忙しくてなかなか顔を出してくれないのよ。

ここはジャワを叩くネタから色々と話しが発展する変なスレだな。
デバッグで疲れるとおじゃばにちょっかい出すとかそんな感じ。
C/C++ネタとジャワ叩きネタならなんでもおけ。

なんだ、おじゃばって若いのかと思ったが、
過去レス見直したら、俺よりおっさんかもしれないのか。すげえな。

なにがすごいって、俺をふくめて、このスレの登場人物の年齢。
マ板で一番、年齢が高いのか？

まず第一にスレッドは立てられん。使ってる2chブラウザの使い方がよく分からないからだ。
第２に俺は、69式おっさんより遥かに若い。

あとやっとチャンクの調査が終わったので、調査報告をしておこう。
間違っていたら誰か訂正してくれ。
まずチャンクが何かを簡単に説明しておこう。
HTTP1.0からHTTP1.1への変更で一番重要なのが、継続的接続への対応だ。
1.0ではGETの度に接続切断を繰り返していたが、接続を続ける事によって負荷を軽減する。
ここで問題になるのが転送サイズ。切断で判断していた転送サイズを別の方法で知る必要がある。
そこでコンテンツ部をある固まりで分割して、そのサイズを表すヘッダーを付けた形式で転送する事に
よって解決した。これがチャンク形式エンコーディングだ。
シーケンスとしては以下の通り。
GETにHTTP1.1と、ConnectionヘッダにKeep-aliveを設定して要求する。
サーバ側ではTransfer-Encodingにchunkedを設定し、コンテンツ部をチャンク変換して返す。

次に調査結果だ。

まず、チャンクされた情報はEtherealでも見ることが出来る。プロキシーサーバを作る必要はない。
次にApache1.3でもチャンク形式エンコーディングされる場合と、されない場合がある。IISは必要ない。
ほとんどの公開されているサーバはHTTP1.0を使用しているようだ。
そのためHTTP1.1のKeep-aliveで送信しても無視される。
そこでApache2.0のサーバを立てて、それに対してHTTP1.1のKeep-aliveで要求してみた。
しかしチャンクされなかった。その代わり、コンテンツサイズはContent-lengthヘッダに設定されて
帰ってきた。ちなみにこのContent-lengthはHTTPでは必須ヘッダではないらしい。
そのため省略されることもあるようだ。
そこでチャンクされるサーバがないか色々試してみた。
すると、あるApache1.3のREDHATサーバが、404の時にChunkedで返してくるのを発見した。

で不明点が2つある。
まず第一にチャンクで返すには、Apacheの設定を変える必要があるのではないか？と変え方。
次に、HTTP1.1のKeep-aliveの要求に、Transfer-encoding無しの、Content-length有りで返すのは
OKなのか？
教えて、HTTPマスター！！

>>922
>過去レス見直したら、俺よりおっさんかもしれないのか。すげえな
どうもそうらしい。それがおじゃばの魅力でもある。

>>922
あとご覧のようにかなり長文なのが最大の特徴かな
まあ悪い奴じゃないのでおじゃばのこともよろしく。

>まず、チャンクされた情報はEtherealでも見ることが出来る。プロキシーサーバを作る必要はない

おいおい、当たり前の事いうなよHTTPプロトコルの定義を言い直してみなさい。

じゃ、なぜﾌﾟﾛｸｼかというと、いらんパケットを見る必要がないからなんだよ。

おじゃばよ、少なくともチャンクの事がよく分かってよかったなあ。
おいらのおかげだな。

>>923
べつに俺もマスターというわけではないが、おじゃばの調査をみるより、こっちのほうがわかりやすくないか？
http://www.tohoho-web.com/ex/http.htm#chunk
http://www.cresc.co.jp/tech/java/Servlet_Tutorial/Lesson_38.htm

>>924

> ほとんどの公開されているサーバはHTTP1.0を使用しているようだ。
そんな事無いと思うぞ。CGIとか、Proxy経由でProxyがHTTP1.0じゃ無いのか？

> チャンクで返すには、Apacheの設定を変える必要があるのではないか？と変え方。
しらん。っていうか、Transfer-Encoding :chunkedって、
Content-Length : nnだとヘッダ送る時点でmessage-bodyの長さを知っていなければならないから
知らなくても、刻み刻みに送信できるようにしつつKeep-aliveができるためのものかと。
サーバが最初からmessage-bodyの長さがわかればContent-Lengthだし
わからなければ(わかろうとしなければ)、chunkedじゃ？

>HTTP1.1のKeep-aliveの要求に、Transfer-encoding無しの、Content-length有りで返すのはOKなのか？
いいんじゃないのか？message-bodyの長さは、
・Transfer-Encoding :chunked
・Content-Length : nnか。
・乱暴にConnection :closeでぶちきれるまでか。
・Content-type: multipart/byteranges;
だから。

ってな感じで相手すればいいのか？ >>みなの衆

おやツワモノがきているな。

おっさんのコテばかりでまるで剣道の道場みたいになってきてるなw

>>930
>ってな感じで相手すればいいのか？
他に比べてまだまだやさしさが感じられるレスだな

66式サラリーage

>927
tcpdumpじゃ見えないとか言われたし、Etherealで見えないのかって聞いた時も返事無しだったぞ。
第一、Ethereal使っていると言ったのに、プログラムで80番を見ろと言ったのは793だ。


>66式
>べつに俺もマスターというわけではないが、おじゃばの調査をみるより、こっちのほうがわかりやすくないか？
そのHPは見た。前者は足りないし後者は長すぎる。その情報をかなり省略して要約したのが俺の説明だ。

>そんな事無いと思うぞ。CGIとか、Proxy経由でProxyがHTTP1.0じゃ無いのか？
チャンクデータを返すHPを教えてくれ。見つからん。Yahooやgoogleなんかは軒並みHTTP1.0だったぞ。

>しらん。っていうか、Transfer-Encoding :chunkedって、
>：
>わからなければ(わかろうとしなければ)、chunkedじゃ？
理論的にはそうだが、実質的にはContent-lengthで事足りるので、あまり使用されていないのでは
ないかと思う。使う場面があるとしたら、検索結果の一覧とかではないかと思うが、最初に長さを
計ってから送信すれば回避出来るし、そもそもみんなが使う検索エンジンは、どんなブラウザからでも
使えるようにHTTP1.0になっているようだ。
実際にチャンクじゃないとまずいパターンって何がある？

>いいんじゃないのか？message-bodyの長さは、
>：
>だから。
ちょっと謎なのが、コネクションの接続を軽減するだけならプロトコルで対応するのではなくて、
コネクションプーリングみたいな機構で出来ないのかと思うが無理なのか？


>793
793はどこに行った？66式とは違う人だよな？
Apacheでチャンク出す設定を教えてくれ。

> チャンクデータを返すHPを教えてくれ。見つからん。Yahooやgoogleなんかは軒並みHTTP1.0だったぞ。
つ http://www.yahoo.co.jp

GET / HTTP/1.1
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; ja; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1
　省略
Host: www.yahoo.co.jp
　省略
Keep-Alive: 300
Pragma: no-cache


HTTP/1.1 200 OK
Date: Tue, 20 Feb 2007 01:58:07 GMT
 省略
Pragma: no-cache
Cache-Control: no-cache
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=euc-jp

12404  
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=euc-jp">
<!--..-->
<title>Yahoo! JAPAN</title>
 省略
0

http://www.yahoo.co.jpはTransfer-Encoding: chunkedだが。おじゃばの環境の問題じゃないのか？

>そもそもみんなが使う検索エンジンは、どんなブラウザからでも使えるようにHTTP1.0になっているようだ。

リクエストがHTTP/1.0ならレスポンスも1.0だろうし、リクエストがHTTP/1.1ならレスポンスも1.1で返さないか？
というバージョンのネゴシエーションがあるんで1.0固定にする意味は無いとおもわれ

googleも同じくchunkedだが。

あと気が付いたけど、
message-bodyがbinaryな場合はTransfer-Encoding: chunkedにしないでContent-Length: nnで送るみたい。
故に、Content-Type: text/htmlでも、Content-Encoding: gzipの場合はContent-Length: nnのようだけど。

なんかのヒントになった？

じじくさい

>そもそもみんなが使う検索エンジンは、どんなブラウザからでも使えるようにHTTP1.0になっているようだ。
こんなこともいい加減でしょうもないなあ。おじゃばよ修行がたりんぞよ。

あとProxyが中継する場合は HTTP/1.0でクライアントからリクエストされた場合
内部のWWWに転送する場合はプロトコルバージョンが合わないと転送禁止
というのがRFC仕様だったぞたしか。ちゃんと調べろよおじゃば!
それじゃあ問題点を自己解決できねえじゃんか

■質問
66式もオパイパブいくんですか?

> ちょっと謎なのが、コネクションの接続を軽減するだけならプロトコルで対応するのではなくて、
> コネクションプーリングみたいな機構で出来ないのかと思うが無理なのか？

すまん何を言わんとしているのかわからん。

コネクションプーリングって、いろんな意味があるからな〜

DBな世界だと、

　1クライアントプロセス-1DBコネクション

だとクライアントプロセスが増えるとDBコネクションも増えてDBサーバが大変だねで

　複数クライアントプロセス-コネクションプールプロセス-少ないDBコネクション

てなことをして、コネクションプールプロセスがプールしたコネクションを
クライアントプロセスに渡す。てなソリューションを指す。

これを真っ先に思いついたんだけど、これかな〜

> Apacheでチャンク出す設定を教えてくれ。

つApacheのソース。
調べても出てきそうになかったら、俺ならこうする。

>>940
オパイパブには行かないですよ。オパイパブには…

66式さん、おじゃばはいつもポインタが微妙にずれるバグ回答するので
あいつはCはできねえんですよね。だからジャワ専なのですよ。

>>935
2点返しわすれた。

> そのHPは見た。前者は足りないし後者は長すぎる。
> その情報をかなり省略して要約したのが俺の説明だ。
それがよいかどうかはノーコメ。自分がいいと思うならいいよ。それ以上言わない。

> 実際にチャンクじゃないとまずいパターンって何がある？
べつにまずいパターンは無いと思うよ。
新しい仕組みが生まれる意味は、「まずい」以外にも「よりよい」があると思うが。

で、今日はここまで。さよ〜なら〜

66式は組み込みじゃないのか？
なぜネットやらサーバーの話を

>66式、939
どうやら俺のProxy環境のせいだったようだ。
あとコネクションプーリングは941で言うように、DBと同じ原理で使えないかって話だったんだけど、
HTTP1.1でKeep-aliveの仕様が出てるならそれでいいか。
あとJava使いとしてはソース解析は否定派なので止めておく。
一応、簡単なCGI作って呼んだら、チャンクされて帰ってきた。
httpd.confにKeep-aliveのOn/Off設定もあったので変えてみたが、チャンクには関係ないようだ。
Apache2.0のデフォルトでは固定ページはレングスで、CGIはチャンクのようだ。

>>946
俺も、なんか、組み込み屋なのにネットやサーバーに詳しいのが不思議
組み込み屋もそんな知識がなければ駄目なんかと思ったりしている
そうなると、組み込み屋ってすげーと思う

組み込みつってもルータとかもあるわけで。

6x式派遣PGとか出てきたらすげえな

今日の仕事おわったんで帰り際。

>>947
お？！これで成仏したかい？

>>946, 948, 949
ここ数年の組み込みワールドは激変したからね〜
消費者向け製品にEtherついているし, USBもHDDもSDカードもBluetoothもついてるし。
中を開けたら、規模は違えどパソコンと変わらん。64bitCPUでSDRAMでPCIだもんw。

てなわけで今時の組み込みにネットワークなんて、ふつ〜う。

受注開発製品だってWebで設定とかあったりする。
これは家庭用ルータがわるい。あれで設定インタフェースはWebでとか言う人が来る。

でも全部が全部というわけでもないから組み込み屋にネットワーク必須ではないかもしれん。

メカニカルな制御の世界なんていうのも組み込み分野ではあるだろうけど、
その世界ならセンサやらモータやらの制御の知識も必要だろうね。
組み込みも分野によって必要な知識の基本＋αのαは違うと思うよ。

とかいったけど、やはりPGのたしなみとしてネットワークは抑えておいて損はないと思う。

ちなみにルータは係わったことないですよ。
DBの話は人からの受け売りです。

成仏w
チーン
なあむうおじゃばあ運送権雲海ぞうりんしいしき
まか南無そわかー

おじゃばは成仏するのに時間がかかるタイプなんだろうな

そろそろVxWorksとか言い出す奴が出没する希ガス

モトローラ命

そういやジャワのリスンサーバsocketって
SO_REUSEADDRオプション指定できるの?できないと浮いたソケットできまくりだもんな。
どうよおじゃば

680x0は美しい石だが、x486の前には完敗だったな。

68Kのころは十分勝ってたろ。問題はその後の失敗。。

68040で486並のクロックまであげられなかったからな

見直したらウソ書いてたよ。

> x86だとswap命令が該当する。
xchgの間違い。

あと、なんかへんだな〜とおもって見直していたら

　while(flag = 1,
　　atomic_swap(&spin, &flag), flag == 0)
　 ;

じゃなくって、

　flag = 1;
　while(atomic_swap(&spin, &flag), flag == 1)
　　;

だ。ボケてたな。

>>954
じゃあ、一言。「高い！」以上。

>>951
そんな組み込み系でのOSって、まさかWindowsじゃないよね、ITRONやLinuxかな

古いCPUの話が出たようなので、私も昔話をひとつ
私が、この世界に入った頃はCで組むと「遅くなって、メモリを使いまくるので商品にならない」と言われた時代でした。Cのコンパイラが動くと数分かかる時代ｗ

という背景で、８０８６コードをアセンブラで書いてました。

データ-配置の方法ですが、いわいるメモリストリングス命令を使うために変数はスタック上。
そしてStaticデータはコードセグメントに置いてました。

現在の感覚とは異なる感覚で、コードを書いていた事を思い出します。
条件文など、今では処理単位で｛｝でくくるのが常識ですが、当時は「JZ アドレス　」つまりはジャンプ先なわけです。

変数を関数に渡す為に、スタックへ値を積み込んでCALL。
BPレジスタと必要なレジスタを保存しながら、コールのチェーンをしていました。
現代ではfunctionから戻った時に、戻り値や参照したところ意外は前の環境と同じ
というのが当たり前ですが、その当時は手間をかけなければ元には戻らない時代でした。

エラーの返し方も、当時はキャリーフラグ（桁あふれフラグ）を使って操作していました。
当時のTrue False です。また一般にはAXレジスタに関数の戻り値をいれていました。

この他にもハードウエァ割り込みや、I/Oポート操作など愉しい？　思い出がありますｗ

さて、Cの文法では関数内に関数を宣言できない。これが大変不満でした。
構築したスタックフレームに乗っかった変数を、そのまま共有できない構造は
アセンブラの構築に慣れた私には、慣れるまでに不便に感じたものでした。

まぁ当時のDOSのCは「メモリモデル」毎にリンクライブラリが異なるなど、
お世辞にも使い勝手が良いとは言えないものでしたしね...

時代が３８６へと変わり、内部的にセグメントを意識しない状態で構築が可能になった時期と、C++の発展がおこりました。C++最強時代の幕開けです。

とりとめもなく駄文を書きました。（呼）んでくれた人へ、どうも有難うございました。

JNZ NEXT
CMP CX, AX
INC BX

あれ66式かとおもいきや
しばらくぶりの68式さんですな