■スレッドリストへ戻る■ 全部 1- 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 最新50

monazilla Part 3

772 :770 :02/12/08 01:06
>>771
そんな仕様があったのか。サンクス

773 :デフォルトの名無しさん :02/12/08 01:16
俺が持ってるネオむぎスレのdat(youth/957323893)は、
2721422バイト 15283レス
2001/03/15 21:35まで。止まるまでにもう少し伸びたと思う。

774 :デフォルトの名無しさん :02/12/12 02:16


775 :デフォルトの名無しさん :02/12/13 10:53
なるほど

776 :デフォルトの名無しさん :02/12/13 10:53
ほう

777 :デフォルトの名無しさん :02/12/13 10:53
と言う事で777ゲット

778 :デフォルトの名無しさん :02/12/13 10:55
無駄に長寿ですな。

779 :bloom :02/12/13 10:57

http://www.agemasukudasai.com/bloom/

780 :デフォルトの名無しさん :02/12/13 14:25
スレのGETの仕方なのだけど、以下のロジックに欠陥はない?

ローカル.datのmtimeは、リモート.datのmtimeに合わせておく。
で、ローカル.datのラスト10レス分を切り出しておく

GET /bbs/dat/key.dat HTTP/1.1
Host: xxx.2ch.net
User-Agent: Monazilla/1.0 (omaemona)
If-Modified-Since: (ローカル.datの時刻)
Range: bytes=(最新10レスの位置)-

if (status == 304) {何もしない(変更無し)}
else if (status == 200) {今回取得したもので、全部差し替え}
else if (status == 206)
{
 if (ローカル.datのラスト10が、今回取得したものの部分集合)
  ローカルのラスト10を、今回取得したものとさしかえ
 else
  あぼーんがあったとみなし、全部取得
}
if (取得した部分があったら)
{
 ローカル.datのmtimeを、リモートL-Mの時刻で変更
}

今、これでちょっとしたツールを動かしているのだけど、
Squidなどのキャッシュ串相手のときは、キャッシュをスルー
させるリクエストを入れないと、206を返してくれなくなる。

781 :デフォルトの名無しさん :02/12/13 14:41
うむ、proxy通す時はPragma:no-cacheは必要だな。
それと、今の2chのapacheは(互換板もだけど)416を返すから対処した方がいい。
もちろん404(302)の他、500等も対処してるよね?

あと、根本的に10レス前から取得する意味がわかんない。
1バイト前じゃだめなの?確かに確実ではないけど。

782 :デフォルトの名無しさん :02/12/14 15:59
>>780
ローカルのファイルシステムがFATだとmtimeを合わせられるとは限らない。

783 :デフォルトの名無しさん :02/12/15 13:47
いつの間にか「Set-Cookie: SPID=」が「Set-Cookie: PON=」に変わってるやんけ!
腹立つぞ。age

784 :780 :02/12/15 14:02
>>781
416は見落としてますた。当方で実験したときは、
206を返せないときは200だったので。

最新10レスを取得しに行くのは、一貫性チェックと
転送量抑制の落としどころを狙ったものです。
1レスだと、手が滑った連続投稿によるズレが識別
できないパターンが考えられて。
1バイトはさすがにどうかと思うんですが。

環境はPerl+LWP on Linuxどす。

>>782
ああそうだ、FATにはそんな仕様があったんだ…

鬱だ氏のう

785 :デフォルトの名無しさん :02/12/15 23:23
>784
既得DATの最後の1バイトは通常は改行文字。
DATは1レスにつき一行だから、改行文字はレスの最後にしか現れない。
だから、あぼーんがあった時に、
チェックした1バイトが改行文字になる確率はけっこう低いと思う。

786 :デフォルトの名無しさん :02/12/16 04:26
test

787 :デフォルトの名無しさん :02/12/16 10:13
シフトジスって改行コード(0x0aだっけ?)が
文字中に出ることはないんだっけ?

788 :デフォルトの名無しさん :02/12/16 16:42
多分大丈夫でし

789 :コロちゃん :02/12/17 06:52
すいません。朝から質問します。

2CHサーバーにPOSTするときの内容で、

「Cookie: NAME=aaaaa; MAIL=aaaaa; SPID=xvsk15.u; PON=99406cf5cc9c19a9e761d0ad11212f3a」

とありますが、このSPIDとPONは何を表しているのでしょうか?
ご存知の方がいましたら、教えてもらえますでしょうか?

お願いします。

790 :デフォルトの名無しさん :02/12/17 07:16
その意味を知っているのは、
ひろゆきと夜勤とマァヴくらいだとおもふ

791 :デフォルトの名無しさん :02/12/17 07:37
SPecialID

792 :デフォルトの名無しさん :02/12/17 11:36
まずはおさらい
(1) Cookieなしで書き込んだら、クッキー警告エラーにして
  Cookieを発行する。
(2) timeがサーバーの現在時刻より新しいか、15秒以内で
  あれば餅つけエラー

793 :デフォルトの名無しさん :02/12/17 11:42
予想される規制
書き込みに成功するたびに、IPと書き込んだ時点でのサーバ時刻の
組をサーバに記録。また同じ情報を暗号化してCookieに含め、
発行する。

(3) 次の書き込みでUAが渡してきたCookieに含まれる時刻が、
  サーバに記録されている時刻より古ければエラーにする
よって同じCookieを使い続けての連書きはできない。

(4) timeがCookieに含まれる時刻より古かったらエラーにする。
よって故意に古いtimeを設定しての連書きはできない。
通常は書き込んだ後で必ずリロードするか新着レスの表示を
行う(すなわち新しいtimeが与えられる)はずなのでこの規制に
かかることはない。

794 :デフォルトの名無しさん :02/12/17 11:44
この規制を導入する前提

すべてのツールは、
・Cookieを取得してそのままサーバに送り返さなくてはならない。
・timeを自分で生成せず、サーバから取得しなくてはならない。
さもなければ(1)〜(4)のどれかに引っかかって書けなくなる。
通常のブラウザはCookieを有効にしていればこの前提を満たす。

795 :デフォルトの名無しさん :02/12/17 18:07
つまり

書き込み時に送るtimeが、
クッキーの発行時間より新しくて
サーバーの現在時刻より古く、
さらに、同じクッキーを使って書き込む場合は
前回書き込み時間より15秒経ってる必要がある
ってことかな?


796 :デフォルトの名無しさん :02/12/17 20:44
> さらに、同じクッキーを使って書き込む場合は
> 前回書き込み時間より15秒経ってる必要がある
> ってことかな?
そうか、よく考えたら前回書き込み時刻はサーバに
あるんだから毎回Cookieを発行する必要はないな。
つーかtimeすら要らないような、、、
ちなみにこれが現時点で導入されてるわけではなくて
たぶんこうなるだろうって予想なので念のため

797 :デフォルトの名無しさん :02/12/17 21:11
で、そのアイデア出したボケはどこのドイツだ?

798 :デフォルトの名無しさん :02/12/17 23:34
他にもasctimeとかdifftimeとかstrftimeとかあったような

799 :デフォルトの名無しさん :02/12/17 23:38
すまん誤爆した

>>797
もちろんあの男に決まってる
http://qb.2ch.net/test/read.cgi/accuse/1040003579/453
453  マァヴ ◆jxAYUMI09s   Date:02/12/16 13:47 ID:s9/3ohLw
>>445
一応5人の人間がその場で検証したし(^_^;)
不安が残るとしたら、提唱者があの男ってことくらいかと・・・・
って、なんかすげー不安になってきたじゃないか(^_^;)

800 :ムー娘。 :02/12/18 06:43


2ちゃんねるサーバーに書き込みを転送する時、HTTPで送ればいいですよね?もちろん。
一応確認を取りたくて・・・。

もしや、FTPとか、だったりして・・。

801 :デフォルトの名無しさん :02/12/18 07:01
独自のプロトコルですが。

802 :デフォルトの名無しさん :02/12/18 08:43
HTTP/2chプロトコルでどうぞ。

803 :デフォルトの名無しさん :02/12/18 09:19
>>802
確かに、最近の動きを見ているとHTTPの上にもう一層プロトコルがある感じだなと。

804 :デフォルトの名無しさん :02/12/18 10:31
SOAP みたいなもんか。

805 :デフォルトの名無しさん :02/12/18 11:49
いっそのことwebサービス化してホスイ

806 :デフォルトの名無しさん :02/12/18 12:29
>>805
ますます重いぞ。


807 :デフォルトの名無しさん :02/12/19 19:26
>
> ひろゆきです。
>
> > それと、サーバから貰った時間て、期限はあるのでしょうか>管理の方々
>
> 期限ないですー。。
>
> 実はですね。timeの数字にはそんなに意味はありませんで、
> timeの欄に乱数を入れるようにしてみようかなぁと思ってたりするんですよ。。
> そうすると、datで逆算もつらくなっちゃうわけで、、、
> ちと、考えます。

あはは

808 :デフォルトの名無しさん :02/12/19 19:29
つーか、何がやりたいのか、さっさと教えてくれると
ありがたいんですが。 > 管理側

809 :デフォルトの名無しさん :02/12/19 22:01
管理側

http://check-it.org/14/log/memo/image/hiroyuki.jpg

810 :デフォルトの名無しさん :02/12/19 23:45
まぁー、こっちはこっちでやりたいようにやるさ。
末期の患者に、通常の意味での「意図」なんて無いと思うし。

811 :デフォルトの名無しさん :02/12/20 03:12
>>1の「投稿日」が従来のdat(から逆算できるUNIXTIME)に
なるようにすればOpenJaneで言うところの「Since」になるし
そうすればdat名だって乱数使えるようになる。

812 :デフォルトの名無しさん :02/12/20 03:13
未取得のスレの立った時間なんて気にする必要ないし

813 :デフォルトの名無しさん :02/12/20 04:09




                 (´д`)




814 :デフォルトの名無しさん :02/12/21 16:49
お気に入りに登録してあるスレッドが次スレに移行したら
勝手にお気に入りも登録し直してくれるシステムを実装してる
2chブラウザってありますか?

こんなのあったら便利じゃないかなっとおもって作ろうか考えたんですけど、
個々のクライアントで実装したほうが現実的だと思いました。

自分はどのプロジェクトにも参加してないのでアイデアくらいしか出せませんが。。。

815 :デフォルトの名無しさん :02/12/21 16:58
>>814
次スレに移行したかどうかはどう判断するの?

816 :デフォルトの名無しさん :02/12/21 17:09
次スレが乱立して後継が揉めたらどうするの?

817 :デフォルトの名無しさん :02/12/21 17:10
>>814
次スレです

monazilla Part 4
http://pc3.2ch.net/test/read.cgi/tech/1029848909/

こういうのはどうする?
結局最終的には人間がサーチすんだよな
次スレっぽいの一覧、とか抽出するだけなら
なんとかなるかも

818 :デフォルトの名無しさん :02/12/21 17:16
1 誰かが手動で登録する
2 subject.txtから○○ Part xxとかのパターンで探す
3 datファイル内のURLをサーチ→リンク先のスレタイでチェック

などなど思いつくけど2,3は重複スレが立つと次スレを一意に決定するのは難しい
1が確実だけど誰かがやってくれないとシステムの普及は難しい。

819 :デフォルトの名無しさん :02/12/21 17:28
>>818
1は、
(a) CGIかなんかで次スレ登録フォームを作って登録してもらう。
(b) 2chブラウザでブックマークを見たときにスレッドがdat落ちしてる模様
(c) スレタイから判断するに次スレがありそう
(d) (a)の鯖に問い合わせ、登録がある場合は次スレの情報をゲット
なんてどう?


820 :デフォルトの名無しさん :02/12/21 18:14
CGIが嵐にあって終了

821 :デフォルトの名無しさん :02/12/21 19:00
したらばみたいに次スレはシステムが自動的に
立てるなら判別できるだろうけどさ

822 :デフォルトの名無しさん :02/12/21 22:47
>>814
navi2ch で試験的な実装があったな。
http://pc.2ch.net/test/read.cgi/unix/1031231315/467-

823 :822 :02/12/21 22:51
おっと、dat 落ちか。
これね。
http://reed1200.tripod.co.jp/navi2ch/sinsure.el

824 :デフォルトの名無しさん :02/12/21 23:02
>>823
(゚∀゚)チェキしますた

825 :822 :02/12/21 23:26
>>822 のミラー。
http://navi2ch.sourceforge.net/test/read.cgi/log/1031231315/
http://navi2ch.sourceforge.net/log/dat/1031231315.dat

826 :デフォルトの名無しさん :02/12/22 05:17
いくつかの方法で複数の次スレ候補を抽出し、
暫定お気に入りに登録。
ユーザーが確認して最終決定。
ってのは?

さすがに完全オートは厳しいだろう。


827 :デフォルトの名無しさん :02/12/22 10:02
単に次スレの URL が貼られたら
右クリックしてメニューから選択、
でもいいかもね。

828 :デフォルトの名無しさん :02/12/22 11:17
キーワード登録してそれに引っかかったらお気に入り登録でいいんじゃない。
"Delphi"を登録したらDelphi談話室、Delphi質問スレの
各バージョンが引っかかるようになる。

829 :デフォルトの名無しさん :02/12/22 12:12
COBOLを登録したら
かなり引っかかるぞ、おい(藁

830 :デフォルトの名無しさん :02/12/22 12:35
スレタイを適当に正規化(全角半角、大文字小文字の統一など)
して、最後に出てきた数字を取り出し現在のスレのそれと比較し
大きいものを候補とすればいいんじゃないかな。
あと、dat名がunixtimeなんだから現在のスレと比較するのも大事。
スレの再利用とかが無い限り現在のスレより新しいはずだから。

831 :828 :02/12/22 13:00
あまり厳密化自動化しすぎると漏れたときに面倒になりそうな。

>>829
OR/AND/NOTで絞り込めるようにしないといけないね。
828の機能は次スレ検出以前にスレッド絞込み・検索機能として欲しいかも。



832 :デフォルトの名無しさん :02/12/22 13:03
>>831
XORも・・・ハァハァ。

と、言うかPerl正規表現にフル対応してくれたらあなたを認定します。


833 :デフォルトの名無しさん :02/12/22 13:16
>>>832
それはやりすぎ(藁
Google互換程度にしないと使いこなせないでしょ。

834 :デフォルトの名無しさん :02/12/22 14:02
>>831
> あまり厳密化自動化しすぎると漏れたときに面倒になりそうな。

俺もそう思う。漏れるぐらいなら、ちょっとぐらい余分なものを拾う方がマシ。

835 :デフォルトの名無しさん :02/12/23 02:35
900番以降の書きこみから同じ板のURLを全て抽出 → 次スレ候補
でいいんじゃない?

いちいちスレッドのタイトル取るのも負荷かかるし。
スレタイが思いっきり変わるのもよくあること。

836 :デフォルトの名無しさん :02/12/23 03:09
自分が次スレ立ててしまえばいいという話もある。

次スレテンプレートを設定しておくと、スレ立て・テンプレ貼り・
現スレへの誘導レス投稿まで自動でやってくれるとかね。


837 :デフォルトの名無しさん :02/12/23 04:04
>>836
まず、既存のブラウザではどれを使っても
スレ立て後に立てたスレを自動的に開く機能が無い
から、そこから作りこみが必要だ。

838 :デフォルトの名無しさん :02/12/23 04:08
>>837
ABoneは開いてくれますよん

839 :デフォルトの名無しさん :02/12/23 07:06
>836
次スレ乱立の予感

840 :デフォルトの名無しさん :02/12/23 12:24
結論:手動が確実。

841 :デフォルトの名無しさん :02/12/23 23:59
次スレを判定するという読み込み系の機能ならまだしも
次スレを立てるなんて書き込み系の機能の自動化は論外だろ。
荒らしツールになるのがオチ。

842 :デフォルトの名無しさん :02/12/24 01:00
>>841
禿同。
せめてスレ立て前に確認ダイアログ出すのは必須、
機能自体もログインユーザに限定とか、ある程度縛らんと荒らしに使われる。

843 :デフォルトの名無しさん :02/12/24 11:48
>840
(・∀・)ソレダ!

844 :デフォルトの名無しさん :02/12/26 02:25
ごめん、>>780あたりの話に戻るんだけど・・・
今、前回取得したスレなら続きのみサーバーから読むのを
やってるんだけどIf-Modified-Sinceじゃなくて
Content-Length使うのは駄目かな?
Content-Lengthで取ってきたサーバーのDATの長さと
ローカルのDATの長さを比較して
1.サーバーのが大きければ続きから取ってくる
2.同じならなにも取らない
3.小さかったら全部読み直し
(あぼーんでサイズが縮んだかローカルが腐ってる)
ちなみに1の場合、実際にサーバーから続きを取る前に
ローカルDATの最後の1行の先頭の位置と長さを求めて
(もしくはあらかじめファイルに記憶しておく)
それをRangeに渡してサーバーから取ってきた内容と比較。
違ってたら、やっぱあぼーんかローカルが腐ってると判断して読み直し。
どうっすか?


845 :デフォルトの名無しさん :02/12/26 04:51
Content-Lengthを取得するためにHEADをして
さらに取得するためにGETする、というような

 無 駄 な 負 荷 を か け る

行為は、このスレでも激しく非難されていますが

846 :デフォルトの名無しさん :02/12/26 11:59
>>844
(゚∀゚)あぼーん以後に書き込みがない なんてことはないですな。

847 :デフォルトの名無しさん :02/12/26 14:39
>846 禿同。
>844 欠陥だらけじゃん。

848 :デフォルトの名無しさん :02/12/26 22:30
>>845
やっぱ無駄な負荷ですか・・・
mtimeがFATだとあわせられる保証がないとか書いてあってんで
サイズにしよかなぁとか思ったんですが。

>>846 >>847
穴ありますか?
あぼーん後、書き込みあって、その後のサーバーのサイズが
ローカルより小さければ再読込するし、
ローカルより大きければ最後の1行チェックでひっかかるだろうし。
サイズか、最後の1行がたまたま同じにならない限りは
大丈夫と思うんですが・・・

849 :847 :02/12/26 23:38
>848 すまん、だらけは言い過ぎだたようだ。

850 :デフォルトの名無しさん :02/12/27 00:14
>>845
Content-LengthはHEADしなくてもGETだけでわかるよ。
ただしヘッダにRangeが必要だったかな。
あと、無意味な空白も無駄な負荷であると激しく非難します。


851 :デフォルトの名無しさん :02/12/27 00:28
じゃあオレは荒れそうなこのスレから避難だ

852 :デフォルトの名無しさん :02/12/27 00:58
TEST

853 :デフォルトの名無しさん :02/12/27 01:19
念のためにいっとくけど、850は皮肉だよ、、
小姑のように二言目には負荷負荷と言われるのは抑圧的すぎるから。
そう鬼の首を取ったように負荷負荷いわれると創造力も減退しそうだ。

854 :デフォルトの名無しさん :02/12/27 02:28
>>853
実際の所、負荷は大問題なわけ。
その創造力で負荷の削減してください。

855 :デフォルトの名無しさん :02/12/27 02:34
       冬厨招来!
           冬厨招来!

       ドンドコ ドンドコ
    ∧ ∧   ,,──,−、
    (,,゚Д゚) / (:  :(  ) ))
     |つ/つ  `ー─``ー'
   〜|  |   ┣━━┫┨
    U U   ┠┤  ┣┫

856 :デフォルトの名無しさん :02/12/27 02:53
漏れは2ちゃんに迷惑をかけるためにあえて高負荷なものを作るけどな。

857 :デフォルトの名無しさん :02/12/27 03:43
>>856
委員長、乙。

858 :デフォルトの名無しさん :02/12/27 04:06
>>854
だから、845はHEADしなくてもいいのに、
HEADするものだと決め込んで、ただ負荷負荷とうるさいわけ。
この決め込みは、発想の貧困化状態を示している。
実際は850で書いたように、
負荷をかけないで、Content-Lengthを取得できるわけだから。


859 :デフォルトの名無しさん :02/12/27 04:24
でも>>844
>Content-Lengthで取ってきたサーバーのDATの長さと
>ローカルのDATの長さを比較して
>1.サーバーのが大きければ続きから取ってくる
>2.同じならなにも取らない

これをどうやって実装するのよ。
「1.サーバーのが大きければ続きから取ってくる 」という事は、
ロールバッグしたRangeヘッダつけたGETを投げちゃうって事だろ。
それのレスポンスからContent-Length調べるって事だろ。
それがIf-Modified-Sinceを付けたGETと比べてどこが優れてるっつーのよ?
同じなら何もとらないもクソも、更新があったらRangeヘッダが付いてる時点で、
サーバーはパケット送って来ちゃうじゃん。
ヘッダを受信した時点で速攻切っても、ファイルIOの負荷が発生するじゃん。
それは 無 駄 な 負 荷 じゃないのか?

860 :デフォルトの名無しさん :02/12/27 04:37
>>859
>それがIf-Modified-Sinceを付けたGETと比べてどこが優れてるっつーのよ?
自分で、意図的に引用から外してわかってるじゃないか。。
> 3.小さかったら全部読み直し
>(あぼーんでサイズが縮んだかローカルが腐ってる)
だろ。
だいたいIf-Modified-Sinceと兼用しちゃいけない理由もないよ。


861 :デフォルトの名無しさん :02/12/27 04:40
>>860
> >>859
> >それがIf-Modified-Sinceを付けたGETと比べてどこが優れてるっつーのよ?
> 自分で、意図的に引用から外してわかってるじゃないか。。

マジで分からないのだけど。
というかね逆に
>やってるんだけどIf-Modified-Sinceじゃなくて
>Content-Length使うのは駄目かな?
この文章から、「If-Modified-Since使うより優れた方法ミツケタ!!」って判断したから、
どこが優れてるの?って聞いたんだけど。

862 :デフォルトの名無しさん :02/12/27 04:44
だから、If-Modified-Sinceも使えばいいんだよ。
その上で、Content-Lengthを読めば、
あぼーん検出の精度少し高めて、
ローカルファイルが壊れているのを検出することもあると
いうことだよ。併用できるので優劣を論じる必要はない。


863 :デフォルトの名無しさん :02/12/27 04:47
>>862
そうだね。
If-Modified-Since”も”使えばいいと俺も思うよ。
でも>>844
「If-Modified-SinceじゃなくてContent-Length使うのは駄目かな? 」
と言っている。
これは「If-Modified-Sinceは使わずにContent-Length使う」と読みとれるだろ。
だから>>845以降突っ込まれてるんじゃないか。

864 :デフォルトの名無しさん :02/12/27 04:50
ん?俺は>>844とは別人だよ。
>>845に対して、単にContent-Lengthを読むこと
についてのみ書いたんだ。
>>844には賛成も反対もない。

865 :デフォルトの名無しさん :02/12/27 04:55
┐(´ー`)┌

866 :デフォルトの名無しさん :02/12/27 08:08
>>864は、話が全く理解できていない、
でファイナルアンサーですね。
863だって、862と844が同一人物だなんて言ってないし。

867 :デフォルトの名無しさん :02/12/27 09:48
>>860
> 3.小さかったら全部読み直し
Rangeを指定していれば縮んだときには416が返ってくる。
分かってないなら素直にIf-Modified-SinceとRangeでGETしとけ。

868 :845 :02/12/27 13:27
他の誰かが代わりに答えてくれてるけど、
850=864って、>>844の文章をろくに読んでないだけじゃん。

869 :デフォルトの名無しさん :02/12/27 14:10
>>844
> 2.同じならなにも取らない

ここにも穴があるね

870 :デフォルトの名無しさん :02/12/27 14:10
>>868
もしくは読んでも理解できなかったか、だな。

871 :デフォルトの名無しさん :02/12/27 17:10
おいおい。。くやしいからって、勝手に論点ずらすなよ。
850=853=858=860=862=864
俺は844については最初から何も触れてないだろ。
>>845に対して、Content-Lengthを読むことについてのみ書いてる。
>>845の間違いはもう指摘した。
俺のどこが間違ってるか指摘しろよ。

226KB
新着レスの表示

スレッドリストへ戻る 全部 前100 次100 最新50

0ch BBS 2004-10-30