[Q]fjのnewsの配送がお かしい場合どこに尋ねるといいですか？

[岡田 健一 / Kenichi OKADA]

おかだです。

fj.news.systemにも振ります．

In the message <m3r8hdl...@nightmare.hm.taito.co.jp>
Takahide Nojima <noj...@taito.co.jp> wrote:

> > 別記事にも書きましたが、本当に SMTP で、NNTPと同等の記事配送サービスが
> > 可能だと考えているのでしょうか？

> 記事配送の効率はともかく、SMTPは事実上どこでも通るし、MLは誰でも使うし、
> それでもMLの方が今のfjのグループ１つ分の一日の投稿量よりはるかに流量は多いし。
>
> で、実際一人が一日に見ているグループの数も、
> 現行のfjの投稿される記事の量から見ても、とてもSMTPで賄えない数の
> ようには思えません。

現状の fj について言うならば、そのとおりだと思います．

フルフィードのリーダ用サーバを、ネットワークトポロジを考えて
最適配置する問題に定式化するならば、サーバは 10～20程度が
適当ではないでしょうか．
fj に限定するならば、20～50ぐらいでしょうか．
SMTPサーバとは、扱う問題の粒度がずいぶんと異なると思います．

> ＃但しbinary*系を除く。
>
> また、何度もいいますが、fjを除く別のニュースグループの事情は知りません。
>
> そのニュースグループがNNTPとINNの配送方式を選ぶなりすればいいかと思います。

SMTPの守備範囲とNNTPの守備範囲、または、とHTTPの守備範囲とNNTPの守備範囲は
多くの部分で重なっていると思います．
いずれのプロトコルにおいても、スケーラビリティがあります．
上で、「NNTPと同等の記事配送サービス」と言っているのは、
全ニュースグループ階層の配送についてです．

> > > ・もっと安定し、
> > > （少なくとも何段にものぼる上流の都合の総意に配送が左右されないような）
> >
> > 総意というのは間違いです．上流が単一であるというのは、
> > 間違った管理方針です．複数の Path を持つ事が推奨されています．

> え？でも、事実上、我々のような末端サイトにとって、上流は一つにしか見えません
> し、選択の余地がなかなかありません。また、複数のPathを安全に持つ為のhowtoも
> 分かりません。INNDのマニュアルにありましたっけ？

選択の余地がないというのは、本当でしょうか？

まず、相互配送先を探す事についてですが、

http://news.yynet.org/netnews.shtml
や
http://www.usenet-se.net/peering/
は、よく紹介されていますし、十分な講読者数が見込めるのであれば、
京大からも配送しています．

nojima さんは、ニュースサーバの管理者ではないのかもしれませんが、
相互配送先が1つでも、2つでも、サーバの設定自体は同じような記述を
追加するだけで済みます．そのための設定はもちろん inn のマニュアルにあります．

> しかも、よそのプロバイダを利用している人にfeedを許可するような太っ腹な
> プロバイダを見たことはないです。さらに、このような事態（囲い込み）は、
> 商業では普通に行われますし、実際このことについて客も文句はいわないでしょう。

一般の個人に対して配送するプロバイダは、国内には少ないです．
プロバイダに限定しないのであれば、有志でfjの配送を行なっている
方々はたくさんいらっしゃいます．

> > > ・もっと反応の早い今時な
> >
> > 大規模分散記事配送サービスにおいて、NNTP より 反応を速くするのは
> > 難しいと思います．

> その大規模配送用途なプロトコルなのに、binary*を除いてfjの記事の
> 流量が大幅に減っているのです。
>
> 自分の印象としては、この現状では、配送にNNTPとINNを使うことは、
>
> 「犬小屋作るのにクレーン車使っている」
>
> ようにしか見えないのです。SMTPで十分じゃないですか？

そうですね．現状程度の量でしたら、SMTPで十分だと思います．
ただ、自発的に登録することが必要なメーリングリストに対し、
NNTPは自由に講読できるという側面も重要ではないでしょうか．

> > 上で挙げているのは、いづれもプロトコル上の問題ではないと思います．
> > 管理コストの問題、コンテンツの品質の問題と、プロトコルの自体問題が
> > 混同しているように感じます．

> では、岡田さんはどうすれば良いと思うのですか？

ftp や irc に目を向けると、これらのサービスは、プロバイダごとに
サービスを提供するという方式ではなく、一部のボランティアによって、
サービスが維持されています．
ネットニュースでも、プロバイダに依存せず、ボランティアベースの
サービス提供方式に転換していくのがいいのではないでしょうか．
Ring Server のネットニュース版のような物を想定しています．

;; Ring Server の ML で、fjなどの提供を提案してみようかと
;; 思った事もありましたが、コンテンツとしての魅力などを
;; 考えて頓挫してしまいました．

fjだけを考えるならば、10程度のサーバがあれば、日本全体のユーザを
カバーできるのではないでしょうか．
fjをボランティアで配送しているサーバもありますが、
それらのサーバが一般の利用者に対して、サービスを開放すれば、
fj のインフラとしての問題は回避できるのではないでしょうか．

もう一つの解としては、プロバイダ間での、ネットニュースサービスの
共有または外注というのがあると思います．
現状のようにプロバイダごとにニュースサーバを提供するのは
現状のサービス規模にそぐわないと思います．
例えば、大手プロバイダ群 (Nifty, Biglobe, OCN, Plala, ODN, DTIなど)は
それぞれでサーバを持たずに、どこか(BiglobeやDTIとか)のサービスを
買い、それぞれプロバイダのユーザに提供に提供するという事です．

サービスを提供するプロバイダに対しても、利用者規模が増加し、金銭的利益に
つながるならば、サービス品質の向上も期待できるのではないでしょうか．

> 「管理を徹底してUsenetに繋ぎなさい」という暗黙の文化がすでに神話になって
> いるようなインターネットのこの状況で、「管理を徹底しなさい」というのを唱えて
> 解決とは、あまりに実行力が薄いように思います。また、fjを活性化するにも、

「管理を徹底してUsenetに繋ぎなさい」の「管理」は、末端の利用者における
セキュリティについてですか？

私は、末端の利用者に対して、ニュースサーバをまじめに管理してくださいと
言いたいわけではありません．
基幹系配送サーバおよび利用者用サーバは、まじめに管理してください
と言いたいです．

> 今はインフラの普及と、現実にあったインフラこそ必要だと思います。コミュニティの
> 文化等は自然とあとから付いてくると思います。

同感です．

--
岡田 健一 mailto:ok...@opaopa.org

[Takahide Nojima]

nojimaです。

＃丁寧なフォローありがとうございます。

ok...@opaopa.org (岡田 健一 / Kenichi OKADA) writes:

> 現状の fj について言うならば、そのとおりだと思います．
>
> フルフィードのリーダ用サーバを、ネットワークトポロジを考えて
> 最適配置する問題に定式化するならば、サーバは 10～20程度が
> 適当ではないでしょうか．
> fj に限定するならば、20～50ぐらいでしょうか．
> SMTPサーバとは、扱う問題の粒度がずいぶんと異なると思います．

？？すみません、後学の為お聞きしたいのですが、何故流量の少ないfjに限定すると
フルフィードのサーバの方がサーバ数が少なくて済むのでしょう？

＃フルフィードのニーズが少ないから？

> > ＃但しbinary*系を除く。
> >
> > また、何度もいいますが、fjを除く別のニュースグループの事情は知りません。
> >
> > そのニュースグループがNNTPとINNの配送方式を選ぶなりすればいいかと思います。
>
> SMTPの守備範囲とNNTPの守備範囲、または、とHTTPの守備範囲とNNTPの守備範囲は
> 多くの部分で重なっていると思います．
> いずれのプロトコルにおいても、スケーラビリティがあります．

了解です。

> 上で、「NNTPと同等の記事配送サービス」と言っているのは、
> 全ニュースグループ階層の配送についてです．

ここなのですが、全ニュースグループ階層の配送とはどういうことですか？
fj.*<->japan.*とかの間の配送のことですか？それとも上流<->下流の話でしょうか？

> > > 総意というのは間違いです．上流が単一であるというのは、
> > > 間違った管理方針です．複数の Path を持つ事が推奨されています．
>
> > え？でも、事実上、我々のような末端サイトにとって、上流は一つにしか見えません
> > し、選択の余地がなかなかありません。また、複数のPathを安全に持つ為のhowtoも
> > 分かりません。INNDのマニュアルにありましたっけ？
>
> 選択の余地がないというのは、本当でしょうか？
>
> まず、相互配送先を探す事についてですが、
>
> http://news.yynet.org/netnews.shtml
> や
> http://www.usenet-se.net/peering/
> は、よく紹介されていますし、十分な講読者数が見込めるのであれば、
> 京大からも配送しています．

現状を教えて欲しいのですが、

・ボランティアベースの配送なのでしょうか？

・Give & Takeの法則に基づき、何かの対価が要求されたりしないのでしょうか？

・feedを受けさせて頂くと仮定して、こちらは1サーバへのfeedなのですが、
可能なもんなんでしょうか？

> nojima さんは、ニュースサーバの管理者ではないのかもしれませんが、
> 相互配送先が1つでも、2つでも、サーバの設定自体は同じような記述を
> 追加するだけで済みます．そのための設定はもちろん inn のマニュアルにあります．

？？同じような設定を追加すると、経路が複数出来上がります。障害が発生した場合、
迅速に原因追求をすることは可能なのでしょうか？

> > しかも、よそのプロバイダを利用している人にfeedを許可するような太っ腹な
> > プロバイダを見たことはないです。さらに、このような事態（囲い込み）は、
> > 商業では普通に行われますし、実際このことについて客も文句はいわないでしょう。
>
> 一般の個人に対して配送するプロバイダは、国内には少ないです．
> プロバイダに限定しないのであれば、有志でfjの配送を行なっている
> 方々はたくさんいらっしゃいます．

なるほどです。でも彼らの、

・運用の資金源はどうなっているのでしょうか？

・管理運営のモチベーションは何？

・対価は？

が不明で少々気になるところです。

＃Usenet時代で聞いたことのある、さらに下流への配送が対価とかいわれるとちょっと困る。

> > 自分の印象としては、この現状では、配送にNNTPとINNを使うことは、
> >
> > 「犬小屋作るのにクレーン車使っている」
> >
> > ようにしか見えないのです。SMTPで十分じゃないですか？
>
> そうですね．現状程度の量でしたら、SMTPで十分だと思います．
> ただ、自発的に登録することが必要なメーリングリストに対し、
> NNTPは自由に講読できるという側面も重要ではないでしょうか．

確かにそれも事実です。いつでも記事が来ているので、好きな時に好きなものが
読め、投稿できるというのは大きい。

> > では、岡田さんはどうすれば良いと思うのですか？
>
> ftp や irc に目を向けると、これらのサービスは、プロバイダごとに
> サービスを提供するという方式ではなく、一部のボランティアによって、
> サービスが維持されています．
> ネットニュースでも、プロバイダに依存せず、ボランティアベースの
> サービス提供方式に転換していくのがいいのではないでしょうか．
> Ring Server のネットニュース版のような物を想定しています．
>
> ;; Ring Server の ML で、fjなどの提供を提案してみようかと
> ;; 思った事もありましたが、コンテンツとしての魅力などを
> ;; 考えて頓挫してしまいました．
>
> fjだけを考えるならば、10程度のサーバがあれば、日本全体のユーザを
> カバーできるのではないでしょうか．
> fjをボランティアで配送しているサーバもありますが、
> それらのサーバが一般の利用者に対して、サービスを開放すれば、
> fj のインフラとしての問題は回避できるのではないでしょうか．

ボランティアでそこまで要求されちゃうと、NetNewsシステムの場合なかなか厳しいような。

＃ircもボランティアベースというのですが、運営の現実はどうなんでしょう。

> もう一つの解としては、プロバイダ間での、ネットニュースサービスの
> 共有または外注というのがあると思います．
> 現状のようにプロバイダごとにニュースサーバを提供するのは
> 現状のサービス規模にそぐわないと思います．
> 例えば、大手プロバイダ群 (Nifty, Biglobe, OCN, Plala, ODN, DTIなど)は
> それぞれでサーバを持たずに、どこか(BiglobeやDTIとか)のサービスを
> 買い、それぞれプロバイダのユーザに提供に提供するという事です．
>
> サービスを提供するプロバイダに対しても、利用者規模が増加し、金銭的利益に
> つながるならば、サービス品質の向上も期待できるのではないでしょうか．

まったくその通りのなのですが、あのめちゃくちゃな量のフルフィードを提供出来る為の資金
は相当なものが必要に思います。

「fj専用配送だけど安い」とかが、ぽこぽこあればいいのでしょうか？

> > 解決とは、あまりに実行力が薄いように思います。また、fjを活性化するにも、
>
> 「管理を徹底してUsenetに繋ぎなさい」の「管理」は、末端の利用者における
> セキュリティについてですか？
>
> 私は、末端の利用者に対して、ニュースサーバをまじめに管理してくださいと
> 言いたいわけではありません．
> 基幹系配送サーバおよび利用者用サーバは、まじめに管理してください
> と言いたいです．

了解です。

でも、以前からまじめな管理が徹底して要求されてきたUsenet Newsの世界ですが、ここに来て
まじめに管理できてないところがちらほらあることから、何か理由があるんでしょうね。
それは何だと思いますでしょうか？

私には分からないのです。SMTP理解する程のパワーがあれば、特にNNTPって難しいわけじゃ
ないし。やっぱし管理者のモチベーションの差かなぁ。

--
Takahide Nojima