Webに向いた新しいファイル構造を考える
■ このスレッドは過去ログ倉庫に格納されています
00011
NGNGファイル構造は、確かに構造が単純で更新が容易ですが、
大量のファイルを伝送したりファイル処理する際には、
ファイルサイズが小さい故にオーバーヘッドが大きく
処理効率が悪くなってしまいます。
また、例えば、検索システムにおいてはWWWロボットが世界中の
数十億というHTMLファイルを収集するので、i-node不足が
課題となります。
だからといって、データベースで一括管理するのでは、
直接ファイルを取得する場合よりも遥かにサーバ負荷が
高くなりますし、応答時間も長くなりがちです。
これらの問題を解決するような研究は無いのでしょうか？
0039デフォルトの名無しさん
NGNG0040デフォルトの名無しさん
NGNGなんだ、ネタかよ。バカは、あっち行ってろ。
でかい画像の本体部なら TCP でもお前らが作るへぼルーチンよりまともな
速度が出てると思うぞ。
0041デフォルトの名無しさん
NGNGサイズが少なくて済む。
0042デフォルトの名無しさん
NGNGおいおい、お前ら大丈夫かよ。ページ内の画像がクライアントから
要求されることは知ってるよな。それとも、タグの分だけ少なくなると
言いたいのか ?
0043デフォルトの名無しさん
NGNG0044デフォルトの名無しさん
NGNGライントレーサでAA化ｗ
さぁ。みんなでRFCに行こう！
0045デフォルトの名無しさん
NGNGああ、やっぱりそう言う知識しかないわけね...。ちなみに IE でも画像
要求しないように設定できることも知らないのか ?
>>43
> ライントレーサでAA化ｗ
変換プログラムがそれなりだったら良いかもしれん。2ch で plug-in
作るか...。
0046デフォルトの名無しさん
NGNG0047デフォルトの名無しさん
NGNGぷぷっ、それしか言えないのか ? ちなみに、Lynx でも plug-in 入れた
ら、画像も要求するぞ。バカは、とっとと帰ってね。
まあ、後半はネタと言われればそうだがな。
0048デフォルトの名無しさん
NGNG0049デフォルトの名無しさん
NGNG0050デフォルトの名無しさん
NGNG0051デフォルトの名無しさん
NGNGLinx って言う Typo を直す前に、ちゃんとした日本語にしろよ。
0052デフォルトの名無しさん
NGNGモノクロ画像にしてくれる delegate サーバがどっかにあった。
intel あたりも転送時圧縮について研究してたはず。
ただ、ユーザが見た目のきれいさを求める方向にある以上、
利用される機会は少なそうだ。
ユーザとしては広告画像だけ選択的に適用したいところだが、
サーバ側としてはオリジナルで見せなきゃいけないものだしなあ。
つうかファイル構造じゃないやん。
0053５
NGNGNetscape 4.0 mailの登場前後に、MIMEタイプ multipart/related を使って、
ページとインライン要素 (リンク含む)を1つのファイルにまとめる技術はあった。
MIME multipart/relatedの、コンテンツ-リンクの表現は、こんな感じ。
コンテンツ側：Content-IDヘッダーで、コンテンツ内ユニークなIDを付ける
【例】Content-ID: multipart/related<[email protected]>
参照側：擬似プロトコル名 cid: を使って、コンテンツのユニークIDを参照
【例】<BODY BACKGROUND="cid:[email protected]">
これって、obsolateな技術なんでしょかね？
0054５
NGNG○【例】Content-ID: <[email protected]>
×【例】Content-ID: multipart/related<[email protected]>
0055デフォルトの名無しさん
NGNGって、そーゆープログラムあるの？
HTTPの要求ヘッダー "accept-type"かなんかで、
表示可能なコンテンツの種類を指定できるから、
画像を欲しがらないブラウザを判別して、
サーバ側でテキスト代替表現を送る事は可能だと思われ。
(漏れはnetpbmの濃淡画像表現くらいしか思い付かなかったけど(w)
0056
NGNG0057デフォルトの名無しさん
NGNGテキスト以外のファイルの検索性が上げれる気が．
0058デフォルトの名無しさん
NGNGRDF
0059デフォルトの名無しさん
NGNG>>57
ってやりたかったんだ->RDF
0060デフォルトの名無しさん
NGNGぼやいてるだけなのに、ちゃんとした日本語もなにもないだろ。
0061デフォルトの名無しさん
NGNGとかできるようになるスキームがW3Cとかで提案されてなかったっけ？
0062デフォルトの名無しさん
NGNGって、IE(かJava)で採用しないと、普及しにくいんだろーな。
0063デフォルトの名無しさん
NGNG0064デフォルトの名無しさん
NGNG全ページのHTMLを単一ファイルにまとめるほうが効果的だと思うけど。
通常は1ページ内に画像ファイルはせいぜい数十個程度しかないでしょ。
0065デフォルトの名無しさん
NGNGMacintosh HFS
0066デフォルトの名無しさん
NGNG復元することでデータの転送量を減らすっていうのはないの？
ちゃんとしたxhtmlなんかは結構圧縮できそうなんだけど。
0067デフォルトの名無しさん
NGNGgzip圧縮指定に必要なヘッダの名前は忘れた...
0068デフォルトの名無しさん
NGNGそれって普通のブラウザ・普通のWebサーバでつかえるの？
0069デフォルトの名無しさん
NGNGmod_gzip。
http://www.planet-green.com/linux/mod_gzip.html
最近のWWWブラウザはたいがいgzip圧縮に対応している(Accept-Encoding: gzipを
送ってくる)ので、サーバ側の負荷よりも回線容量を重視したい場合には有効。
0070デフォルトの名無しさん
NGNG調べがたりんかったｽﾏｿ。そして>>67 >>69ありがと。
これって要求のたびに圧縮してるのかな。
静的なhtmlなら一度だけ圧縮しておけばCPU不可はほとんどかからないんじゃ？
そういうオプションもあるのかな？ もうすこし調べてみるわ。
# うちのプロバイダで使えるのだろうか？
0071デフォルトの名無しさん
NGNGHTMLファイルじゃないがftp://ftp.turbolinux.co.jp/pub/TurboLinux/にその例がある。
0072デフォルトの名無しさん
NGNGこのままだとおそらくサーバ側の話にならないぞ。
0073デフォルトの名無しさん
NGNG0074デフォルトの名無しさん
NGNG>>1 の疑問に素直に答えるならば、i-nodeが足らないなら増やせばいいし、
オーバーヘッドは問題にならない（なると思うのならその理由を示してくれ）し、
だとしてもそれはOSでキャッシュもったり先読み&遅延書き込みしたり、
でいいじゃん。っていうか、DBにしたところで速くならないよ。
0075デフォルトの名無しさん
NGNG10000ファイルを一つ一つ処理するより、1ファイルにまとめて処理したほうが
ディスクのシーク時間が節約できる・・・はず
0076デフォルトの名無しさん
NGNGプロクシで圧縮して送るという方法もあるな。
0077デフォルトの名無しさん
NGNGウェブサーバーとプロクシサーバーの間は圧縮していないデータが通るから変わらないのでは？
0078デフォルトの名無しさん
NGNG0079デフォルトの名無しさん
NGNG同じ画像を違うページから参照すること、良くあるからねぇ。
たしかに、用途によっては１つのファイルにまとめるのが便利ってこともあるが。
小さいファイルが山ほどあるとオーバーヘッドが、という話は、
これがhttpリクエストを何度も送らなきゃならない/そのたびに
TCP接続のハンドシェークが起きる、というような話であるなら、
Keep-Aliveとパイプラインで解決だ。
ところで、i-node不足ってことは、サーバのファイルシステムを
考え直せ、ってことかいな？ Webの構造とは関係ない次元だと思う
のだが？
0080デフォルトの名無しさん
NGNGRAMディスクでマウントすればいい。
CGIはC/C++で書いてmmap。dbは使用しない。
0081デフォルトの名無しさん
NGNG「ファイル構造」の話なのか、どっちよ？
0082>79
NGNGFTPにはkeep-aliveに相当するものは無いと思う。
0083デフォルトの名無しさん
NGNG1 の話からすると webarchive や google クラスを想定してそうだ。
google のキャッシュって何GB？それともTB行ってるんだっけか？
0084
NGNG0085デフォルトの名無しさん
NGNG0086デフォルトの名無しさん
NGNGNOOPとか。
0087デフォルトの名無しさん
NGNGではFTPの代わりにscpを。
0088デフォルトの名無しさん
NGNGコネクション張った状態でも取得回数分の通信遅延は避けられないと
思うんですけどー
0089デフォルトの名無しさん
NGNGいやだから、パイプライン使えばいいじゃん、って。
HTMLの構造的な問題に着眼するなら、ファイルをバラバラに
取得するのは欠点というより、キャッシュを有効に活用する
ための利点である、というふうに思うのだが、間違いかな？
0090でも
NGNG実装が面倒だから自分でコード書くときは逐次処理しちゃうよね
0091デフォルトの名無しさん
NGNG0092
NGNG0093デフォルトの名無しさん
NGNG0094デフォルトの名無しさん
NGNG0095デフォルトの名無しさん
NGNG0096デフォルトの名無しさん
NGNG独自プロトコルと独自ファイルフォーマットで比較的Closedな
環境ｷﾎﾞﾝ。
2CH/IPと、2CTプロトコル、2ctファイル形式。
定義は頼んだ。
0097デフォルトの名無しさん
NGNGHTTP(TCPまでも?)を使わない独自プロトコルの2chもどきシステムで、
匿名性とデータ転送の効率をアップさせたいと言うのは面白い考えだと思う。
だが、一言言わせてもらうと、それはスレ違いだ。
0098デフォルトの名無しさん
NGNG0099
NGNG0100デフォルトの名無しさん
NGNGおもしろそうだがクライアントアプリの開発が難しくなるんじゃない
誰かが一緒に部品も提供すればいいのか。
0101デフォルトの名無しさん
NGNG0102
NGNG0103デフォルトの名無しさん
NGNGTCPまでもってのは難しいのでTTCPを使うとかは？
単なるミーハー？
0104デフォルトの名無しさん
NGNG変換プロキシかませばいいんじゃない。
サーバーとローカルで。
さらに盗聴されても大丈夫なように画像とかに偽造する。
0105デフォルトの名無しさん
NGNG○いいんじゃない？
0106テスト
NGNGすでに圧縮されている画像や動画を圧縮してもしょうがない。
新しいプロトコルを作るなら、
テキストはテキストだけ、画像は画像だけ、動画は動画だけのプロトコルを作って欲しい。
そもそも、画像とテキストが同じ http プロトコルというのが嫌い。
汎用性持たせ過ぎは嫌い。
日本語も表示できるようにしてしまったため、
文字コード処理がめんどうくさくなった。
欧米人もちゃんとした英語使えないんだから、英語だけでいい。
日本語表示したいなら、特定コード以外は、
エラーとしてはじくようなプロトコルを作って欲しい。
自殺したプログラマの何割かは、日本語コードのせい。
0107デフォルトの名無しさん
NGNG＞画像は画像だけ、動画は動画だけの
その画像なり動画なりも特定の形式のみサポートでしょ？（特定の形式のみに最適化しないとそのプロトコルはただのバイナリ転送プロトコル）
技術の発展を遅らせる。
0108デフォルトの名無しさん
NGNGつーか逆に単純なしくみで全てをまかなえるほうが理想だと思うが。
ＨＴＴＰは無計画にオプションを追加しまくった形跡ありありで
機能の重複も多いし
すでにお世辞にも単純なプロトコルとは言い難い。
クライアントを作るだけなら全ての仕様を使う必要がないから
まだいいが
まともに仕様を満たすサーバーやプロクシを作ろうとすると
死ぬ思いをする。
これは外部に開かれたCGIやWebアプリも同様。
0109
NGNG0110
NGNG0111デフォルトの名無しさん
NGNGなんか不安定みたいだけど。
0112
NGNG0113デフォルトの名無しさん
NGNG0114
NGNG0115デフォルトの名無しさん
NGNGこれがネットワークでやり取りされるデータの構造なんだ、と感動した。
0116
NGNG0117デフォルトの名無しさん
NGNG0118
NGNG0119デフォルトの名無しさん
NGNG規制ゆるくなった？
0120デフォルトの名無しさん
NGNG■ このスレッドは過去ログ倉庫に格納されています