192 lines
14 KiB
Text
192 lines
14 KiB
Text
From dmr Thu Jan 30 17:00:03 EST 1992
|
||
誠に申し訳ありませんが、MH front end はあと１週間だけ待って下さい。
|
||
新しい xterm のために vtwin の変更が必要となって、それにちょっと
|
||
手間取ってしまいました。まだもう１つ直したい bug があるのですが
|
||
もう今日は時間がありません。
|
||
拝啓 新緑の候、ますますご清祥のこととお喜び申し上げます。
|
||
さて、斎藤信男先生は４月１日をもちまして、慶応義塾大学理工学部教
|
||
授に御昇任なられました。そこで、日頃斎藤先生にお世話になっている
|
||
私達が斎藤先生に お祝いを申し上げるためのささやかな 祝宴を企画致
|
||
しました。当日は 斎藤研究室 OB/OG の方々、斎藤研究室現役の学生、
|
||
また、斎藤先生ゆかりの方々が集まり、斎藤先生を囲んで楽しいひとと
|
||
きを過ごしたいと考えております。ご家族、御友人おさそいあわせのう
|
||
え御列席下さるようお願い申し上げます。
|
||
おそれいりますが、ご出席の確認を下記連絡先に電話または電子メール
|
||
にてご連絡下さるようお願い申し上げます。
|
||
敬具
|
||
「斎藤信男教授を囲む会」
|
||
日時： 昭和６２年４月２４日（金） 18:00 より
|
||
場所： 新橋第一ホテル「レストランクラレット」
|
||
電話； 03-501-4411
|
||
会費： １万５千円 （当日記念品代１口５千円を別に御用意下さい。）
|
||
ただし、学生料金は別途設定してありますので御安心！
|
||
連絡先:中村 修 osamu@keio.junet
|
||
電話 044-63-9137 （斎藤研究室直通）
|
||
電話 03-704-4715 （中村自宅）
|
||
幹事代表 村井 純、 中村 修
|
||
拝啓 新緑の候、ますますご清祥のこととお喜び申し上げます。
|
||
さて、斎藤信男先生は４月１日をもちまして、慶応義塾大学理工学部教
|
||
授に御昇任なられました。そこで、日頃斎藤先生にお世話になっている
|
||
私達が斎藤先生に お祝いを申し上げるためのささやかな 祝宴を企画致
|
||
しました。当日は 斎藤研究室 OB/OG の方々、斎藤研究室現役の学生、
|
||
また、斎藤先生ゆかりの方々が集まり、斎藤先生を囲んで楽しいひとと
|
||
きを過ごしたいと考えております。ご家族、御友人おさそいあわせのう
|
||
え御列席下さるようお願い申し上げます。
|
||
おそれいりますが、ご出席の確認を下記連絡先に電話または電子メール
|
||
にてご連絡下さるようお願い申し上げます。
|
||
敬具
|
||
「斎藤信男教授を囲む会」
|
||
日時： 昭和６２年４月２４日（金） 18:00 より
|
||
場所： 新橋第一ホテル「レストランクラレット」
|
||
電話； 03-501-4411
|
||
会費： １万５千円 （当日記念品代１口５千円を別に御用意下さい。）
|
||
ただし、学生料金は別途設定してありますので御安心！
|
||
連絡先:中村 修 osamu@keio.junet
|
||
電話 044-63-9137 （斎藤研究室直通）
|
||
電話 03-704-4715 （中村自宅）
|
||
幹事代表 村井 純、 中村 修
|
||
ＪＵＳ幹事の皆様：
|
||
４月１０日の幹事会でお話した、次のような講演についての件ですが、
|
||
発内容：Ｍａｃｉｎｔｏｓｈ ＩＩへのＵＮＩＸの移植
|
||
発 者：米国ＵｎｉＳｏｆｔのエンジニア
|
||
発時間：１時間（幹事会において決まった時間です）
|
||
発当人からＡＢＳＴＲＡＣＴが届きました。このような内容での話でよけれ
|
||
ば、来日するがどうだろう？との問い合わせがあったのですが、皆様いかがでしょうか？
|
||
皆様の御意見を伺ったうえで、本当に来てもらうかどうか当人に連絡したいと思います。
|
||
（交通費、宿泊費などはＪＵＳから出す必要はありません）
|
||
御返答、よろしくお願いいたします。
|
||
ＤＣＬ 坂本 文
|
||
ＪＵＳ幹事の皆様：
|
||
４月１０日の幹事会でお話した、次のような講演についての件ですが、
|
||
発内容：Ｍａｃｉｎｔｏｓｈ ＩＩへのＵＮＩＸの移植
|
||
発 者：米国ＵｎｉＳｏｆｔのエンジニア
|
||
発時間：１時間（幹事会において決まった時間です）
|
||
発当人からＡＢＳＴＲＡＣＴが届きました。このような内容での話でよけれ
|
||
ば、来日するがどうだろう？との問い合わせがあったのですが、皆様いかがでしょうか？
|
||
皆様の御意見を伺ったうえで、本当に来てもらうかどうか当人に連絡したいと思います。
|
||
（交通費、宿泊費などはＪＵＳから出す必要はありません）
|
||
御返答、よろしくお願いいたします。
|
||
ＤＣＬ 坂本 文
|
||
次回のｊｕｓ幹事会は下記の場所で行います。
|
||
日時 ５／８（金）午後６時
|
||
場所 （株）アスキ―、ＦＦＦビル、７Ｆ役員会議室
|
||
地図
|
||
至赤坂
|
||
国道２４６号（青山通り）
|
||
| |*（地下鉄表参道Ｂ３出口）
|
||
| | （ラ―メン屋）
|
||
紀ノ国屋| |出光GS 天下一
|
||
| | 住 大 Ｆ*
|
||
| | 友 仁 Ｆ
|
||
| | 南 堂 Ｆ
|
||
至渋谷 青 ビ ビ
|
||
山 ル ル
|
||
ビ
|
||
ル
|
||
（１）地下鉄表参道駅下車、Ｂ３の出口を出る。
|
||
（２）青山通りを渋谷方面へ歩く
|
||
（３）初めての信号（角が出光ＧＳ）を右へ曲る
|
||
（４）約５００Ｍ歩き（信号４つ目）、Ｔ字路の交差点の右側
|
||
（５）ＦＦＦビルの７Ｆ
|
||
ＰＳ．当日１４：４０着の便で成田に帰って来ますので、少し遅れるかもしれません
|
||
が先に始めて下さい。
|
||
この間の集りでマーク・シートの読み取りのsoftの話題があったと思うので
|
||
すが，「インタフェース５月号」の新製品紹介の欄で，ANK character の読み取りの
|
||
softの紹介があったように思います。
|
||
ただ，その雑誌がいま，手元にないので詳しくはわかりませんが，調べてみ
|
||
ます。
|
||
一部の人は知っていると思いますが，現在 rmap のＰＤ化を進めています．
|
||
余分な機能をそぎ落し，一通り動くようになりました．あと，２，３
|
||
新たな機能を追加する予定ですが，問題はその前提となる rwhod にあります．
|
||
御存知のように rwhod はつながるマシンの数が増えると，急激に network 及び
|
||
CPU を食いはじめます．また，routing の機能がないため複数のネットワークが
|
||
接続されているような環境ではやはり問題です．東工大ではいままで，gateway
|
||
となるマシンの rwhod に手をいれて routing をするようにしていましたが，
|
||
その場しのぎのいい加減なやり方だったので，４月にネットワークの接続形態が
|
||
変って以来，２重に packet を流していたことが判明しました．昨日急いで
|
||
直しましたが，それまでネットワークは collision の嵐だった訳です．
|
||
たかだか３０台のネットワークでこの有様ですから，何百，何千という
|
||
本格的ネットワークを考えると単純に routing を行う今の方法は非現実的です．
|
||
そこで，いくつかのアイディアを加藤君と考えました．
|
||
1. broadcast packet は止めて，ＮＦＳを利用し /usr/spool/rwho をできる限り
|
||
共有する．どうしても必要なところは point-to-point で routing を行う．
|
||
2. routing する場合に独自のプロトコルにより複数のホストの情報を
|
||
1 packet で送る．
|
||
3. on demand で必要な時だけ他のマシンに対し情報を要求する．
|
||
トリガーは，例えば誰かが rmap でそのマシンを含むページを表示しようと
|
||
した時とする．
|
||
4. どうせ，そういう情報が必要なのは phone をかけたい時ぐらいだから，
|
||
むしろ，phone を改造して phoned が broadcasting や routing をしながら，
|
||
特定のユーザがどこにいるか探し回るようにする．
|
||
さて，そこで皆さんの意見を聞きたいと思います．どうするのが一番良いでしょうか．
|
||
今考えているのは，1, 2 の機能を持った public domain rwhod を作るといった
|
||
ところですが，果してそんなことをするのは意味があるのか．４を実現すれば事実上
|
||
rmap はいらなくなるんじゃないのか．有益な議論をお待ちしています．
|
||
私は前の mail で次ぎのようなことを書きました．
|
||
> 御存知のように rwhod はつながるマシンの数が増えると，急激に network 及び
|
||
> CPU を食いはじめます．また，routing の機能がないため複数のネットワークが
|
||
> 接続されているような環境ではやはり問題です．東工大ではいままで，gateway
|
||
> となるマシンの rwhod に手をいれて routing をするようにしていましたが，
|
||
> ....，何百，何千という
|
||
> 本格的ネットワークを考えると単純に routing を行う今の方法は非現実的です．
|
||
> そこで，いくつかのアイディアを加藤君と考えました．
|
||
> 1. broadcast packet は止めて，ＮＦＳを利用し /usr/spool/rwho をできる限り
|
||
> 共有する．どうしても必要なところは point-to-point で routing を行う．
|
||
> 2. routing する場合に独自のプロトコルにより複数のホストの情報を
|
||
> 1 packet で送る．
|
||
> 今考えているのは，1, 2 の機能を持った public domain rwhod を作るといった
|
||
> ところですが，果してそんなことをするのは意味があるのか．...
|
||
今考えていることを，もう少し具体的に説明すると，
|
||
既存の rwhod は自分のマシンの network configuration を見て
|
||
自分の属するサブネットワークにはすべて broadcasting で，
|
||
point-to-point のリンクにはその相手先に対し，自分のマシンの情報のみを
|
||
流しまています．
|
||
私が手を入れた rwhod はそれらに加えて，他のマシンから来た
|
||
情報を自分の spool に書き込むと同時に，リストとして貯め込んでおき，
|
||
自分の情報を流す時に同時に，個々のマシンの属するネットワーク以外の
|
||
すべてのリンクにその情報をリレーするというものです．
|
||
しかし，この方法だといくら broadcast packet を使ったところで，
|
||
論理的にはネットワーク全体が完全グラフをなすように packet を
|
||
流すことになりますし，しかも普段はそういう情報を必要としない
|
||
場合が多い訳ですから，明らかに供給過剰です．で，これを少しでも
|
||
軽減することができれば，と考えている訳です．
|
||
新しい rwhod は，様々なネットワーク上の制約を盛り込めるように，
|
||
例えば /etc/rwhod.rc のようなファイルからリレーのための configuration
|
||
を読み込むようにするといいでしょう．そのファイルの中に書かれるべき
|
||
項目としては，次ぎのようなものが考えられます．
|
||
1. 自分のマシンの情報をどのマシン，またはどのネットワークに対して
|
||
送信するか．また，それをローカルファイルに格納するか否か．
|
||
2. 他のマシンの情報をどのマシン，またはどのネットワークに対して
|
||
リレーするか．それは packet として受信されるべきものなのか，
|
||
ＮＦＳによってそのマシンの rwhod が書き込んだファイルを
|
||
読みにいくのか．前者の場合には，さらにその情報をローカル
|
||
ファイルに格納するか否か．
|
||
3. 1, 2 は何秒間隔で行うのか．
|
||
これらに加え，さらに通常は packet を流さずに必要な時だけ，
|
||
rwhod が他のマシンに対し情報を要求するという機能を付け加えるのも
|
||
いいかもしれません．このためには，/etc/rwhod.rc の中に
|
||
4. あるマシンの情報に対する要求があった時にどのマシンに
|
||
対して問い合わせを行うか．
|
||
という項目を付け加えるべきでしょう．1,2,4 は実際には統一した
|
||
フォーマットで記述するのがいいかもしれません．
|
||
もし，こういう on demand 型のサービスを取り入れると当然 rwho, ruptime, rmap
|
||
といった client 側にも変更が必要になります．恐らくあるマシンの情報を得るには，
|
||
といったようなライブラリ関数を用意することになるでしょう．
|
||
この関数は自分のマシンの rwhod に対してそういう request を
|
||
行い response を受け取るという単純なものにするのがいいと
|
||
思います．一方その request を受け取った rwhod はスプールを
|
||
見てそれが充分新しいものであれば，そこから読み取り，そうでなければ
|
||
rwhod.rc に書かれたマシンに対し問い合わせることになるでしょう．
|
||
いや，もうそこまでするのだったら，いっそスプールは全廃して
|
||
rwhod が on core で情報を管理した方がいいかもしれません．
|
||
というようなところが今まで考えたところですが，そこでこの前にも書いた
|
||
疑問に戻ります．果してこんなことをする意味があるのだろうか？
|
||
phone を hack すれば，それで問題は解決するのではないか？
|
||
何か意見を言ってください．お願いします．
|
||
私はこれを今度の meeting で議論してもらいたいとは思っていません．
|
||
あくまで mail で意見を聞かせて下さい．そうすることで，
|
||
議論がたまたま meeting に出席した人の中だけでの閉じたもので
|
||
終るということがなくなると思いますから．
|
||
ところでこの mailing list はいつまで東工大で管理されているのですか．
|
||
u-tokyo に移した方がいいのではないのですか？
|
||
|