タイトル: NetNewsサービスの現状と問題点ーーNetNewsなんてもういらない！？ ---------------------------------------------------------------------------- logger: 千坂文男（ＷＬＷ） 外山勝保（Internet Multifeed Co.) ---------------------------------------------------------------------------- 1) NetNewsに関する統計的現状 発表者： 民田 雅人(MINDA, Masato) トラフィックについて トラフィック推移の歴史 これまでの流量の平均値について説明 フルフィードでのアーティクル数はそれほど大きな変動は少ないが トラフィックのサイズは確実に増加している。 本気でフルフィードするならT1以上は必要！ 確実な増加が続いているが今後の流量について正確な予想は困難 フルフィードは現状でT1を潰すほどの膨大なトラフィックである 安易に受けるとトラブルの元 ---------------------------------------------------------------------------- 2) ISPという立場からみたNetNews 発表者： 谷口 崇(TANIGUCHI, Takashi) 現状の運用は比較的安定してきた。 ９７年 １日６．４GB １日６０万通 ９８年 １日１２GB １日８０万通 ほぼ２倍の流量 C News -> INN -> Diablo いかにスムーズに流すか 受け付け専用 peer用 集約用 顧客向け用 などサーバの役割によって切り分け効率化を図っている INN -> Diablo (切替えた時は6GB、今は12GB) Diabloの特徴を説明 ニュースの配送 INNからDiabloへ変更した理由 最近の記事の数やサイズ cancelへの対応が楽 現状の運用について 泣きごとはいってられない 顧客とのやりとりで INN -> Diablo へ変更を勧めるとラインのトラフィックが埋まって しまう。 課題 購読系が受け切れなくなってきた 配送方法について マルチキャストは？ リーダが対応したらいいかも Diabloの限界はとりあえずT1まであればなんとかなるかな ---------------------------------------------------------------------------- 3) NetNews Group Adminからみた現状 発表者： 松田 浩平(MATSUDA, Kouhei) ネットニュースの初期(２０年前？)は１７０MBで１週間もつような時期もあった 配送経路が複雑になりトラフィックが増えてきた Microsoftという文字を含んだ記事をrejectすると流量の９２％を押えること ができた。 japan はバイナリが９０％くらい １.６GB ８万通 利用者の増加、特定多数から不特定多数へ 記事にMicrosoftという文字が含まれることが多くなった。 これからも配送を本当にやっていくならば、セキュリテイはそれなりの覚悟でのぞむこと パスワードをcatするような記事が多くなった B News では そのままのNG が作られる ---------------------------------------------------------------------------- 4) NetNewsにおけるSPAMの現状 発表者： 菊池 文村(KIKUCHI, Ayamura) スパムのフィルター EMP スパムのcancel処理にも負荷がかかる INNの最近のフィルタ(サイバースパム)の紹介 フィルターをかけるのは自由であるが、ISP側で対応の窓口を 設定するべきである。 現状は対応がとれていない。 NetNewsは根本的にコストが高い、止めるか有料のサービスに するか。 国でも諮問機関の設定などがでてきたようだが、基本的に あてにできない！(^.^;) ---------------------------------------------------------------------------- 5) NetNewsシステムソフトウェアの現状と今後の展開 発表者： 近藤 雄公(KONDOU, Katsuhiro) 商用ソフト cyclone tphoon 　　　　＃　大体、数千ドルくらい フリーソフト INN 2.0 Diablo 1.16test2 技術的な問題点 RTT ihave -> check/takethis レスポンスの向上 Spool方式 1ファイル 1記事 1ファイル 複数記事(CNFS) フィルタ方式 記事の到着後 -> 受取時に対応 cmsgの処理 pgpにより認証 フィルタ Diablo ホスト名でチェック、あまりよくない Cyclone perlによるフックがある INN 投稿時のコネクションで制約をかけられる ニュースリーダ用サーバ Diablo 未サポート 今月末ごろにリリースしたい INN ? フィルタの記述 cleanfeed バイナリじゃないグループにバイナリの投稿をリジェクト など、なかなか便利。 管理にてまがかかるがどのくらいといったことを明確に 把握することができない。 ---------------------------------------------------------------------------- 皆ネットニュースをよんでいますか？ 半分くらい ディスカッションなどの場として有効か？ - ---------------------------------------------------------------------------- 6) 討論「NetNewsサービスの現状と問題点」 発表者： 菊池 文村(KIKUCHI, Ayamura) 発表者： 近藤 雄公(KONDOU, Katsuhiro) 発表者： 佐藤 美樹(SATOU, Miki) 発表者： 谷口 崇(TANIGUCHI, Takashi) 発表者： 塚本 悟(TSUKAMOTO, Satoru) 発表者： 松田 浩平(MATSUDA, Kouhei) 発表者： 民田 雅人(MINDA, Masato) 発表者： 矢萩 茂樹(YAHAGI, Shigeki) ・会場の人々は、ネットニュース読んでいるか？　　半々 ・ネットワーク上でディスカッションする場として有効な媒体だと思うか？　。。。 ・INN1.7から2.0へ変えた場合、spoolの構造も変わりそうだが、 　よい移行の方法はあるのか？（会場A） ・makehistoryでできる。（近藤） ・80万通のうち、どれくらいの割合がよまれているのか（会場B） ・IIJ4Uの場合、２台のサーバを用意しているがそろそろ足らない。 　**万通程度が読まれているようだが、夜中にダウンロードして 　読む人もいるため、正確な数字ではない。（谷口） ・新聞の記事のうち、読まれているのは２％（松田） ・エロバイナリの転送が多い。これに高いコストがかかり、 　最終的にISPのお客にコストが転嫁されるのはたまらない。（菊池） ・認証はどうすればよいか（矢萩） ・ダイアルアップのドメイン名でアクセスコントロールする。 　どのユーザアカウントで投稿したのかは追いかけることができる。 　辞めた会社のアカウントを利用するケースもある（塚本） ・NTTの場合も調べることができるが、ダイアルアップのログを 　何年分も取っておくことは不可能。警察から２年は保持しろ、と言われた。（佐藤） ・Japanについては、非公式だがPGPでcontrolメッセージを流している。 ・fjでもPGPの試行している。うちではrmgroupは無視、newgroupは受け入れ。 　checkgroupを主導で一月ごと。（会場C） ・fjとjapanの違い。fjのほうはthresholdが高いので攻撃性が低い。 　japanの方がthresholdが低いので、いろいろな不正・匿名記事が多い。 　受けるならば覚悟をすべき。結局、認証よりも、中継するかしないかが重要（松田） ・Newsのバックボーンを大手ISPが作るべきでは（会場A） ・コスト負担が関係するので反対。（橘） ・ダイアルアップも含めてポストした人のログを残すことはシステム的にできるか（橘） ・やってできないことではないが、現実的ではない（近藤） ・管理が大変。コストを使う人に転嫁すべき。やめた方がよい。メーリングリスト 　でないとできないのはなぜ？（山本） ・NetNewsはやめるべき。（菊池） ・ヘッダをISPがそのユーザのアドレスをつける等すれば抑止になるのでは。（会場D） ・ISPが中身を関知できない。有料なら責任を持たなければならなくなる。（谷口） ・外国でお金をとっているところもある。日本ではみんな無料になっているだけ。（会場E） ・端末側ソフトでキャンセルを入れないなどの工夫も必要。（会場F） ・「NetNewsを使わない」割引をISPが導入すればよい。ユーザもそういう意見を 　ISPに言うべき。（岡本） ・*.binariesをやめれはよい。NetNewsをやめるのではなく。（会場C） ・コストをちゃんと計算して話をすすめないと、会社的に説得できない（近藤@IIJ） ・JANOG comment として、強制力はないが、JANOGに参加している人の 　合意として出していきたい。（近藤@IIJ） ---------------------------------------------------------------------------- [EOF]