2ch特化型サーバ・ロケーション構築作戦 Part35

＞むむむさんへ

以下の投稿についてちょっとお聞きしたいのですが。

p2から投稿すると　[―{}@{}@{}-] がでる場合があります。
最初はp2側でp2-bbmが送られなかったりすることがあるのかな？と思いましたが無関係のようです。
なぜこういう状態になるのか教えて欲しいです。

また、可能であれば表示しないようにしていただけませんか？
投稿そのものには影響もないので特に問題ではありませんがよろしくお願いします。

p2で投稿。
------------------
http://qb5.2ch.net/test/read.cgi/operate/1258647584/344
344 名前： [―{}@{}@{}-] cw43.razil.jp(441031)[sage] 投稿日：2009/12/01(火) 13:20:34 ID:sZbl/bAkP
てすと
Monazilla/1.00 (P2/p2.2ch.net; p2-client-ip: 123.108.237.26; p2-user: 441031; p2-bbm: 354018011067091)
------------------

直接投稿 （c.2ch.net経由）。
----------
http://qb5.2ch.net/test/read.cgi/operate/1258647584/362
362 名前：w12.jp-t.ne.jp(354018011067091)[sage] 投稿日：2009/12/01(火) 17:45:23 ID:eZ0EvHluO
つして
SoftBank/1.0/911T/TJ002/SN354018011067091 Browser/NetFront/3.3 Profile/MIDP-2.0 Configuration/CLDC-1.1
----------
123.108.237.26 -> w12.jp-t.ne.jp
同じIPアドレスを経由しているのにp2の場合だけ表示される。

それと、123.108.237.26　自体は焼かれています。

BBQに焼かれているっぽいけど。
http://hikarin.jp/c/check?ip=123.108.237.26&query=all

bbs.cgiはソースみてみたけど問題なさげでした。

>>728
ありがとうございました。

p2側に何かあるって感じですかね？
ちょっとakiさんにも聞いてみます。

ところで、bbs.cgiのp2処理はp2-client-ipを確認しBBQされていた場合は串マークをつけるという処理になっていると思うのですが
たとえばですが、123.108.237.26が携帯キャリアのアドレスとして認識されておらず一般回線（PCから）として認識されている可能性というのはないでしょうか？

この場合だと焼かれたIPアドレスからの投稿において串マークが表示されてしまうのも納得なんですが。

あー、p2からの投稿に関してはPCも携帯も処理は同じ（区別しない）で、
たまたまキャリアのゲートウェイが焼かれていると串が表示される、という感じですかね？

それなら納得ですが。

＞なぜこういう状態になるのか教えて欲しいです。
p2で投稿→P2扱い≠携帯扱い
直接投稿→携帯扱い
携帯はBBQはスルー（BBMでチェック）なので、
p2でレスするとBBQに引っかかってねぎまが表示されると。

＞また、可能であれば表示しないようにしていただけませんか？
そもそもこのホストって携帯なのに何故にBBQされたんでしょ？

>>729
P2が持っている携帯IPアドレスリストから漏れているんじゃないかしら

p2.2ch.net総合スレ Part25 【不具合/要望】
http://qb5.2ch.net/test/read.cgi/operate/1184674851/262
> 262 名前：aki ◆...p2/2... 　[]　投稿日：2007/08/04(土) 21:39:19 ID:FdSmDf8h0
> BBQなら携帯固有番号は関係ないです。
> 固有番号はBBMで別途チェックしています。
>
> DoCoMo, au, SoftBankのIPはBBQの判定対象から外すようにしてみました。

p2からの投稿は以前に、串からの投稿は串マークをつけようってなったんですよね。
で、bbs.cgi的にはp2からの投稿はそのクライアントが携帯かそうでないかによらず
ただクライアントのIPアドレスを持って「BBQされたホストかどうか」を判断していると。

＞そもそもこのホストって携帯なのに何故にBBQされたんでしょ？
携帯のゲートウェイってちょくちょく焼かれてますよ。

>>732
いや、それはp2が投稿を受け付けるかどうかの判断であって、
2ちゃんねる上の串マーク表示の判断は2ちゃんねるで行っていると思うです。

で、ですがp2はBBMされていると投稿できません。
つまりBBQされているかいないかなので、「携帯で投稿できる=焼かれてはいない」という判断が可能だと思うです。

そこでbbs.cgiで　p2 からの投稿であり、かつ　p2-bbm　が存在している場合はBBQ表示チェックをスルーするということは可能でしょうか？
cgiの負荷で考えると外部にBBQのチェックをしに行かなくなるので負荷的には軽くなるんではないかと思うのですが。

＞p2はBBMされていると投稿できません。
もし、BBM判断をp2側で処理していない場合（2ちゃんねるのBBM処理に依存している場合）でもBBQをチェックする必要はないと思うのです。

なるほど。
ところでbbs.cgiってどうやって更新すればいいんだろう？

むむむさん待ち？
SunOsさんもできるのかな。

>727
ちょと見てきました。
w12.jp-t.ne.jp <123.108.237.26>は、焼けていましたので解除しておきました。

お、なんとなくそれっぽい呪文を発見。
でも怖いので見なかったことにしよう。

7765行目
if($GB->{P2BBM}) { return 0; }

7894行目
if($ENV{HTTP_USER_AGENT} =~ /p2-bbm: (\w+)/)
{
$GB->{P2BBM} = $1;
}

備考
BBMチェックはされない。

>>738
意外なところから、ありがとうございました。

>>739
＞ 7765行目
BBQの串表示チェックする関数かな？

＞ 7894行目
p2処理部のp2-bbmチェックかな？
この行はp2以外の投稿は通らないんですよね？

＞BBMチェックはされない。
>>735に対するものかな？
やっぱりp2側で弾いているってことか。

今日は深夜まで帰宅できない見込み。
数分しかオンラインになれないけど、何をどうすればいいのかな。

よくわからないので、コンセプトだけ書いておこう。

p2導入のメリットとして、規制系チェックはできるだけp2側でやるようにすることで、
掲示板サーバのコストを下げるということがあります。
ということで規制のチェックは基本的に、p2側でやってもらっているです。
BBMはp2側でチェックして、だめならbbs.cgiに行く前の段階ではじかれるはずです。

ピンポイントで焼かれた携帯には焼かれた理由があるはずで、
それがp2だと書けるようになる、というのは、２ちゃんねる的にどう考えてもおかしな話です。
繰り返して言いますが、p2は規制回避の道具ではありません。

ただし、BBQは初代管理人の方針により、焼かれていても投稿はできるようにするが、
串マークはつける、というふうになっていたはずです。

で、p2で悪いことした場合は速やかにアカウントを焼く、
というのが、流儀なわけです。
つまり、アカウントとりまくりに対しては、焼きまくりで対抗すると。

＞741
BBMをスルーした携帯が
p2で書くと無駄なBBQチェックをされて
名前欄にねぎまがくっつく
＞739で解決だけど反映方法がわからないのであった。

で、時間切れ。
garnetさんからメール来ている気がするけど、今時間なくて返事できないです。
とりあえずそれが配布プログラムなような気がするけど、
修正するときには全体の「コンセプト」を、きちんと把握した上で、
つまりそれがどうして今そうなっているのかを把握した上で、するのがいいかと。

>>742
> BBMをスルーした携帯

どうしてそんなことが?

●だとスルーだったりする?

あう、まじ時間切れだ。

焼かれた携帯はどんな手段をもってしても金輪際おことわり、
しか道はないと思われ。

スルーじゃない、パスだ。すまそ。
正しくは「p2のBBM検査をパスした携帯が」

>>744
BBMされていない携帯でp2を使い投稿すると
携帯のゲートウェイがBBQされている場合に
串マークが付いてしまいます。

概略：
本来、BBMされていない携帯なのでBBQをあえてチェックする必要はないはずなので

　携帯＋p2＋BBMされていない場合は　串マークをつけるかどうかのチェック　をスルーしていただきたいです。

違うな。

概略：
携帯からの投稿はあえてBBQをチェックする必要がないはずなので

携帯＋p2の場合は　串マークをつけるかどうかのチェック　をスルーしていただきたいです。

>>741の
＞ただし、BBQは初代管理人の方針により、焼かれていても投稿はできるようにするが、
＞串マークはつける、というふうになっていたはずです。
で>>727ってことで終わりじゃない？

FreeBSD 8.0 Benchmarked Against Linux, OpenSolaris
http://www.phoronix.com/scan.php?page=article&item=freebsd8_benchmarks&num=1
Mac OS X 10.6.2 vs. Ubuntu 9.10 Benchmarks
http://www.phoronix.com/scan.php?page=article&item=macosx106_ubuntu910_final&num=1
FreeBSDがアレなのは良いとして、OpenSolarisやMac OS Xが面白い傾向を見せてるなぁ。
OpenSolarisはカーネル内にsslのアクセラレータ(KSSL)があるから、それでopensslのベンチが高いのかな。あとZFSは遅いという印象持ってたが、改善されてる感じ。
Mac OS XはLinuxに比べて高かったり低かったり。何が影響してるかは推測が付かないなぁ。

携帯のゲートウェイがBBQされてることのほうが問題なのでは。
bbs.cgiでケアする問題ではないと思います。
2ch的に意味ないし。

もうすぐ03でもオフラインになるます。

>>749
それはBBQをチェックする投稿の場合です。
海外からの投稿だとかね。

そもそも携帯はBBMであってBBQを参照しないので、p2経由の場合だけBBQチェックを行うのは意味がないです。
さらに、それが規制のためであるならまだしも、ただ表示に串マークをつけるだけに行われているのですから
「掲示板サーバのコストを下げる」おちう趣旨にも合致します。

それとBBMされた携帯からは以前より投稿はできません。

＞ということで規制のチェックは基本的に、p2側でやってもらっているです。
＞BBMはp2側でチェックして、だめならbbs.cgiに行く前の段階ではじかれるはずです。
この部分を知らなかったので、2ちゃんねる側で弾いているのかp2側で弾いているのか分からないけど、
いずれにせよ、携帯＋p2がBBQを参照するのは意味がないです。

で、>>748に対してもう一つレスしておくと、

・if文を増やしたくない

これに尽きます。

これにてしばらくオフライン。

>>751
携帯＋p2の投稿でBBQを参照する必要ってありますか？


訂正：
2ちゃんねる側で弾いているのかp2側で弾いているのか分からなかったけど

2ch的には『携帯+p2の場合』ifを増やしたくないって事かなぁ

大それた不具合でも、セキュリティホールでもないしなあ。

でも気分的問題は影響がでかいような

ゲートウェイが焼かれているのが問題なのだから、
単にBBQを解除すればいいだけの話では？

# 携帯用のゲートウェイを使って悪さする人っているのか？

むりやり投稿。

コストの問題なのかな。

すべての投稿に対し毎回実行されるif文が一つ追加されるコストか、
たまに無駄撃ち確実なBBQ参照を行ってしまうコストか。

if文か、、、

・if文が増える
　管理コストの増大
　分岐処理によるコストの増加

・BBQ参照
　参照時のコスト

BBQがどういう仕組みか分からないけど、通常のDNSと同等であるなら
初回に限り外部に照会、2回目以降はローカルで解決
ってなると、常に発生する分岐コストよりは低いのかもしれないのかな

まぁ今は忙しいようなので手が空いたときにでもまた、、、

ガーネットさんありがとうです。

そもそも、携帯のゲートウェイはどういった経緯で焼かれているんだろう。

そのifが通常ケース(P2+携帯以外)において分岐ミスしなければ、そのコストは無視できるぐらい限りなく小さいと思いますが。
#ただし高級言語で書かれている場合は知りませんが

一部の携帯で串マークが出る>>726のは、携帯のゲートウェイが焼かれてたから>>727
このときの串マークはbbs.cgi側で挿入されてたと>>732

ところで、規制系チェックはできるだけp2側でやる>>741ので
p2でBBQをチェックしている>>732？？のなら、
bbs.cgiで再びチェックする必要はないんじゃね？

と大きく拾ってみた

最初はBBQが焼かれているなら原因をつきとめて解除すればいいと思った＞728
携帯のGWはちょくちょく焼かれているみたい？＞733
ifいれてp2+携帯はBBQチェックをスルーするようにした方がいいかも？＞736
コストはどっちが大きいんだろ？

>>758
いやそうでもないっすよ。

焼かれていてもいなくても初回は必ず照会に行きますが
2回目から、
・焼かれている場合→ローカルで解決する→即座に応答できる
・焼かれていない場合→ローカルで解決しないのでBBQ照会→常に照会していることになる
むしろ焼かれていたほうがレスポンスは上がると思います。

＃もちろん普通のDNSキャッシュの仕組みで動いている場合ですけど。

>>763
いえ、p2の投稿で「BBQされたホストからは串マークをつける」というのがあるのでそのためのBBQチェックだと思います。
代理人の意向、、、かな。

>>765
処理コストの為にわざと焼かれたままにしておくのっておかしくないかい？

>>758
これは?
SoftBank Mobileの携帯用GatewayをPCで通る方法のメモ
http://d.hatena.ne.jp/hideden/20090801/1249142985

>>766
いやん
あくまでコストで見ただけですので、それが正しいって意味じゃないですぅ＞＜

＞ちなみにIMEI番号はほとんどの携帯のダイヤル画面で *#06# と入力すると調べる事が出来る。
ほんとに表示された。
知らなかった。

で思いついたんですけど。（叩かれるの覚悟で・・・）

少なくともp2の投稿という処理に関しては分岐が発生しているはずですよね？

で、問題となっているのが
（１）BBQ参照はすべてのホスト/端末で行われている
（２）その中で分岐が増えるのはよろしくない
（３）p2からの投稿はp2-client-ipを引数にしてBBQ参照を呼んでいる
　　　　（このため、クライアントが通常ホストか携帯端末（のゲートウェイ）かという区別がない）
（４）p2-bbmがあるときだけBBQ参照を行わようにしたい
（５）　（１）が呼ばれる都度、（４）の実行が行われることになる
というものですね。

たとえばですがp2に限ってはBBQ参照チェックもp2にゆだねといて　UAに p2-bbq　なるデータを付加させるというのはどうですか？
この場合、p2投稿時はBBQ参照を通らないので（４）（５）の必要はなくなります。
結果、（1）の動作において分岐は増えないのでコストの増加は防げる

これの問題点は
・p2の時だけ特別処理になること
・p2そのものの負荷が増える
・akiさんと協調が必要
・串マークが付くだけでそれほど重要な問題でもないのに大げさじゃないかな
・やるのがめんどくせー

p2もBBQを参照してるんでしょ？ゆだねても負荷そんなに増えるのかしら？

>>771
いや、多分していないはず。
だってBBQされていても投稿できるでしょ？
そのためのp2でもあるし。

以前はしていたようだけど、多分はずされていると思う。

＃ただし、今後の「焼かれたホストからはさらに担保を貰う」が現実になった場合はその限りではありません

ああー『してた』のかー
森担保も動きがさっぱりだからどうなんかねぇ

そもそもなぜ携帯のゲートウェイがBBQに入ってんの？
公開串じゃないじゃん

まぁ実際にログあさってソース見つけたわけでもないので、たぶんということで。

p2サーバの増強が実現して重くなることがなくなればそういう処理を入れてもらえるかもしれないけどね。
ただせさえ重いときがあるのにそういう処理を入れたら怒られちゃいそう。

>>774
手動で焼いたのか、自動で焼いたのかってところだよね。
けど、ドメインから携帯端末って分かると思うから手動って言うのはないと思うんだけど。

つまりさ、解除してもまた焼かれる可能性っていうのは常にあるんじゃないかと。
だから解除すれば問題なしってだけの話でもないと思う。
むろん、解除したほうがいいのはそのとおり。

>774
おそらくBOOとか。
（トラブル等で正出来ませんと問答無用で登録された気が。。。）

>>767
これって割とまずい気がするのっておいらだけ？

>>767
そういえばhttpsはヘッダも暗号化されるからその場合x-jphone-uidを偽装出来る予感…。それ考慮してないサイトはヤバそうな。

>>778
わたし、ちゃんと読んでないって言うのもあるけど、
そういう系の話って良く分からないんだよね。

ただ、IMEI番号が偽装できるのなら、アブナイと思う

>>767
テザリングを巡るSBとの攻防の副産物だね。

そういえば、DNSって「名前解決出来なかった」っていうのもキャッシュされるんだっけ？

そのゾーンに定義された negative cache TTL 秒数だけキャッシュされる

携帯のipは昔からbooとかで焼けてるやつ混じってる
何を今更

あーそうだったよねー
>>765は正しくないなぁ

(´-`).｡oO(　ごめんなさい　すあまさん　)

ちょっと教えて欲しいんだけども、携帯のGWってどういう条件でbooされてるの？

w12.jp-t.ne.jp　は　BOO2BBQだったそうです。

BOOしたけど通信上のエラーなどで逆引きができなかったりしたとき、逆引き不可で焼かれちゃうんじゃないですかね？
前に未承諾さんが(別件のかも？）タイムアウト値を変えるとか言ってたしそういう関係かも。

>>782 >>785
「名前解決できなかった」というのに2種類あって
・権威ゾーンサーバに query を出したら NXDOMAIN が返ってきた
→Negative cache TTL 秒数だけキャッシュ
・権威ゾーンサーバに query を出したがタイムアウトまでに返事がない
→スタブリゾルバの実装次第だが一般的には再度 query を出す

>787
一時期BOOに誰かが流し込みすぎて
BOOの機能自体がアップアップしていた時期もありました。
そんな時に偶然焼けるホストが出てくる可能性もあるかもです。。。

>>788
なるほど、
前者の場合ならキャッシュされるからコストの差は少ないと。
後者の場合は実装依存ということですね。

>>789
スクリプトで流す人がいるのかも知れないですね。
そんなときに偶然焼けちゃうことがあると。。。