[Q] 投稿量少ないのは何故？
岡田 健一 / Kenichi OKADA
ネットニュースのシステム自体での議論でもありますので、
fj.news.system にも振ります．
In the message <m3vg6pl...@nightmare.hm.taito.co.jp>
Takahide Nojima <noj...@taito.co.jp> wrote:
> > > > まずは、サービス品質向上のために、サーバ管理者の努力を
> > > > 期待します．
> > > > 配送遅延と記事漏れの対処は、サーバ管理者の努力で回避できます．
> >
> > > 配送遅延を減らしてもHTTPベースの掲示板/SMTPベースのMLには
> > > 更新スピードは結局勝てないように思います。
> >
> > 本当ですか？ まともに管理された Path を辿る限りは、
> > 更新スピードは 10秒以下ぐらいになります．
> > (fj.news.adm.feed-check,fj.testなど参照)
> >
> > 1. 集中管理型 Web掲示板
> > 2. 分散管理型 Web掲示板
> > 3. SMTPな ML
> >
> > を考える場合、1では更新スピードは速いですが、集中的なアクセスには
> > 弱いです．すると、改良形として 2が考えられますが、更新スピードでは
> > NNTPに分があると思います．
> > 3 について、利用者が1000人を越えるような ML の場合、NNTPが
> > 有利なのは明かです．
> 了解しました。更新速度10秒は知りませんでした。
>
> では、なぜにこんなにも掲示板に不向きなHTTPとSMTPが非常に多くのコミュニティ
> を築いているのか（しかも、HTTPに至っては、某Web掲示板のような莫大なユーザ数
> を築ける）のか不思議です。
利用者層を考えると、特別 クライントを設定する必要のない HTTP が
とっつきやすいからというのが理由ではないでしょうか．
また、小規模掲示板には、HTTP は適所だと思います．
逆に、2ch ぐらいに大規模になると 集中型 HTTP では管理が大変なのでは
ないでしょうか．
分散型 Web掲示板を実装するために、裏で NNTP による配送を行なうという
アイデアも前々からあるようです．
> また、何故こんなにも掲示板に向いているはずのNNTPでfjへの投稿量が
> 減りまくっているのも不思議です。
>
> また、Web掲示板が登場した1996年あたりから偶然にもfjへの投稿量が減り続けて
> いるのも不思議です。
こちらは fj の閉鎖性が原因の一つにあるのではないかと思っています．
一番支配的な原因が何であるかはわかりません．
> もし、おっしゃる通り、NNTPが配送に向いており、HTTPはどこのサイト
> でも通るという事実があるなら、
>
> [1] HTTP上にNNTP通して、
>
> [2] コンピュータに詳しくない人でも
> 簡単に設定が可能な個人利用専用のニュースリーダ＆サーバを作り
> （GUIなニュースリーダ兼ニュースサーバみたいな物を用意）
>
> [3] 各地にいくつかある配送の安定したサイトから、
>
> [4] ユーザが指定のしたグループの配送がMLのようにさっさと受けられる
>
> [5] で、Keep Aliveを検知するなんらかの方法を実装しておき、ユーザがパソコンの
> 電源切ったらその間feedも停止し、
>
> [6] ユーザがツールを立ち上げれば、電源切れたときから現在までのfeedが開始
> される。
>
> ようなソフトを作れば、インフラの問題は解決できそうですが、
> いかがなもんでしょうか？
まず、上記の実装を評価する際に、
1. サービス立ち上げコスト
2. 運営コスト
3. 通信量
4. クライアントからの講読コスト
を考えます．1.2.3. を考えると、 [3]で言われているような各地に
いくつかある配送の安定したサイトがあるだけで、末端まで配送する必要は
ないのではないでしょうか．
また、そのようなサイトで、NNTP<->HTTPのgatewayサービスを
提供すれば、4 の基準も満せるのではないでしょうか．
> > > しかも、今のNewsSystemのように、上流でここの議論にかかわらず
> > > 日夜ウン百ギガ/日も無駄な通信が行われ続けているようなインフラ
> > > で何とかしようというのも不毛な努力に思えてなりません。
> > >
> > > fjは相対的に技術系の人が多いに違いないので、きっとエレガントな次の
> > > プロトコルを編みだし、技術的回答を得ることが出来るんじゃないでしょうか？
> >
> > 分散型メッセージサービスの方式としては、NNTPはエレガントな
> > (というか一番まっとうな)プロトコルだと思います．
> > 本当にプロトコルが問題なのでしょうか？
> > コンテンツの配送方針の方が問題となっているのではないでしょうか．
> 質問なのですが、配送方針とはどのようなことを指しますでしょうか？
すいません．あいまいでした．
NNTPのプロトコル内で、
1. どれほど末端まで配送するか．
2. どのニュースグループを配送するか
3. バイナリを配送するか (どの記事をバイナリとするか)
という方針です．
講読者が欲っする記事により配送する記事の量は決まると思います．
NNTPがスケーラブルなプロトコルである事を意識しつつ、
NNTPサービスを提供してほしいという事です．
--
岡田 健一 mailto:ok...@opaopa.org
Takahide Nojima
丁寧なフォローありがとうございます。
ok...@opaopa.org (岡田 健一 / Kenichi OKADA) writes:
> > では、なぜにこんなにも掲示板に不向きなHTTPとSMTPが非常に多くのコミュニティ
> > を築いているのか（しかも、HTTPに至っては、某Web掲示板のような莫大なユーザ数
> > を築ける）のか不思議です。
>
> 利用者層を考えると、特別 クライントを設定する必要のない HTTP が
> とっつきやすいからというのが理由ではないでしょうか．
なるほどです。それであれば、ぽこぽこfj.1st-readmeで謂われている
・NNTP<->Webインターフェース
・NNTP<->SMTPンターフェース
の機構は今こそ必要な時でしょうね。
というわけで、fj.1st-readmeから、SMTPインターフェースと、Webインターフェース
についての記述をはずして欲しいな。
> また、小規模掲示板には、HTTP は適所だと思います．
了解です。
> 逆に、2ch ぐらいに大規模になると 集中型 HTTP では管理が大変なのでは
> ないでしょうか．
そうですね。あそこの掲示板の凄いところは、管理が超大変なのは
あそこの管理者軍団（？）だけで、ユーザにはつゆ程もそれを感じさせない
ところです。
> 分散型 Web掲示板を実装するために、裏で NNTP による配送を行なうという
> アイデアも前々からあるようです．
なるほど。面白いですね。そのうち、2ch.hogeとかのNewsgroupが出来るのかなぁ
> > また、何故こんなにも掲示板に向いているはずのNNTPでfjへの投稿量が
> > 減りまくっているのも不思議です。
> >
> > また、Web掲示板が登場した1996年あたりから偶然にもfjへの投稿量が減り続けて
> > いるのも不思議です。
>
> こちらは fj の閉鎖性が原因の一つにあるのではないかと思っています．
良く巷でfjの閉鎖性がとやかくいわれるのですが、どう閉鎖しているのか自分には
全く理解できません。
実際、自分の質問や、このとおりの議論が閉鎖的な扱いを受けたという実感は無いですし。
もしよかったら、例はありますか？
> 一番支配的な原因が何であるかはわかりません．
そうですね。真実を知る必要があれば、フィールド調査と統計的手法による調査がいるでしょうね。
> > [6] ユーザがツールを立ち上げれば、電源切れたときから現在までのfeedが開始
> > される。
> >
> > ようなソフトを作れば、インフラの問題は解決できそうですが、
> > いかがなもんでしょうか？
>
> まず、上記の実装を評価する際に、
>
> 1. サービス立ち上げコスト
> 2. 運営コスト
> 3. 通信量
> 4. クライアントからの講読コスト
>
> を考えます．1.2.3. を考えると、 [3]で言われているような各地に
> いくつかある配送の安定したサイトがあるだけで、末端まで配送する必要は
> ないのではないでしょうか．
> また、そのようなサイトで、NNTP<->HTTPのgatewayサービスを
> 提供すれば、4 の基準も満せるのではないでしょうか．
なるほどです。これは良いですね。
＃あとは、クライアントの実装だけの問題だし。
> > 質問なのですが、配送方針とはどのようなことを指しますでしょうか？
>
> すいません．あいまいでした．
>
> NNTPのプロトコル内で、
>
> 1. どれほど末端まで配送するか．
> 2. どのニュースグループを配送するか
> 3. バイナリを配送するか (どの記事をバイナリとするか)
>
> という方針です．
> 講読者が欲っする記事により配送する記事の量は決まると思います．
> NNTPがスケーラブルなプロトコルである事を意識しつつ、
> NNTPサービスを提供してほしいという事です．
なるほど了解です。つまりフルフィードしているようなところは避け、ユーザのニーズに
合わせて接続可能な地点を作るということですね。
確かにこれが出来ればある程度そのままでインフラの問題は解決しそうです。
＃あとはそのような太っ腹な接続先をさがすことになりますなー
--
Takahide Nojima