1 From dmr Thu Jan 30 17:00:03 EST 1992
2 誠に申し訳ありませんが、MH front end はあと1週間だけ待って下さい。
3 新しい xterm のために vtwin の変更が必要となって、それにちょっと
4 手間取ってしまいました。まだもう1つ直したい bug があるのですが
6 拝啓 新緑の候、ますますご清祥のこととお喜び申し上げます。
7 さて、斎藤信男先生は4月1日をもちまして、慶応義塾大学理工学部教
8 授に御昇任なられました。そこで、日頃斎藤先生にお世話になっている
9 私達が斎藤先生に お祝いを申し上げるためのささやかな 祝宴を企画致
10 しました。当日は 斎藤研究室 OB/OG の方々、斎藤研究室現役の学生、
11 また、斎藤先生ゆかりの方々が集まり、斎藤先生を囲んで楽しいひとと
12 きを過ごしたいと考えております。ご家族、御友人おさそいあわせのう
14 おそれいりますが、ご出席の確認を下記連絡先に電話または電子メール
18 日時: 昭和62年4月24日(金) 18:00 より
19 場所: 新橋第一ホテル「レストランクラレット」
21 会費: 1万5千円 (当日記念品代1口5千円を別に御用意下さい。)
22 ただし、学生料金は別途設定してありますので御安心!
23 連絡先:中村 修 osamu@keio.junet
24 電話 044-63-9137 (斎藤研究室直通)
27 拝啓 新緑の候、ますますご清祥のこととお喜び申し上げます。
28 さて、斎藤信男先生は4月1日をもちまして、慶応義塾大学理工学部教
29 授に御昇任なられました。そこで、日頃斎藤先生にお世話になっている
30 私達が斎藤先生に お祝いを申し上げるためのささやかな 祝宴を企画致
31 しました。当日は 斎藤研究室 OB/OG の方々、斎藤研究室現役の学生、
32 また、斎藤先生ゆかりの方々が集まり、斎藤先生を囲んで楽しいひとと
33 きを過ごしたいと考えております。ご家族、御友人おさそいあわせのう
35 おそれいりますが、ご出席の確認を下記連絡先に電話または電子メール
39 日時: 昭和62年4月24日(金) 18:00 より
40 場所: 新橋第一ホテル「レストランクラレット」
42 会費: 1万5千円 (当日記念品代1口5千円を別に御用意下さい。)
43 ただし、学生料金は別途設定してありますので御安心!
44 連絡先:中村 修 osamu@keio.junet
45 電話 044-63-9137 (斎藤研究室直通)
49 4月10日の幹事会でお話した、次のような講演についての件ですが、
50 発内容:Macintosh IIへのUNIXの移植
52 発時間:1時間(幹事会において決まった時間です)
53 発当人からABSTRACTが届きました。このような内容での話でよけれ
54 ば、来日するがどうだろう?との問い合わせがあったのですが、皆様いかがでしょうか?
55 皆様の御意見を伺ったうえで、本当に来てもらうかどうか当人に連絡したいと思います。
56 (交通費、宿泊費などはJUSから出す必要はありません)
60 4月10日の幹事会でお話した、次のような講演についての件ですが、
61 発内容:Macintosh IIへのUNIXの移植
63 発時間:1時間(幹事会において決まった時間です)
64 発当人からABSTRACTが届きました。このような内容での話でよけれ
65 ば、来日するがどうだろう?との問い合わせがあったのですが、皆様いかがでしょうか?
66 皆様の御意見を伺ったうえで、本当に来てもらうかどうか当人に連絡したいと思います。
67 (交通費、宿泊費などはJUSから出す必要はありません)
72 場所 (株)アスキ―、FFFビル、7F役員会議室
86 (1)地下鉄表参道駅下車、B3の出口を出る。
88 (3)初めての信号(角が出光GS)を右へ曲る
89 (4)約500M歩き(信号4つ目)、T字路の交差点の右側
91 PS.当日14:40着の便で成田に帰って来ますので、少し遅れるかもしれません
93 この間の集りでマーク・シートの読み取りのsoftの話題があったと思うので
94 すが,「インタフェース5月号」の新製品紹介の欄で,ANK character の読み取りの
96 ただ,その雑誌がいま,手元にないので詳しくはわかりませんが,調べてみ
98 一部の人は知っていると思いますが,現在 rmap のPD化を進めています.
99 余分な機能をそぎ落し,一通り動くようになりました.あと,2,3
100 新たな機能を追加する予定ですが,問題はその前提となる rwhod にあります.
101 御存知のように rwhod はつながるマシンの数が増えると,急激に network 及び
102 CPU を食いはじめます.また,routing の機能がないため複数のネットワークが
103 接続されているような環境ではやはり問題です.東工大ではいままで,gateway
104 となるマシンの rwhod に手をいれて routing をするようにしていましたが,
105 その場しのぎのいい加減なやり方だったので,4月にネットワークの接続形態が
106 変って以来,2重に packet を流していたことが判明しました.昨日急いで
107 直しましたが,それまでネットワークは collision の嵐だった訳です.
108 たかだか30台のネットワークでこの有様ですから,何百,何千という
109 本格的ネットワークを考えると単純に routing を行う今の方法は非現実的です.
110 そこで,いくつかのアイディアを加藤君と考えました.
111 1. broadcast packet は止めて,NFSを利用し /usr/spool/rwho をできる限り
112 共有する.どうしても必要なところは point-to-point で routing を行う.
113 2. routing する場合に独自のプロトコルにより複数のホストの情報を
115 3. on demand で必要な時だけ他のマシンに対し情報を要求する.
116 トリガーは,例えば誰かが rmap でそのマシンを含むページを表示しようと
118 4. どうせ,そういう情報が必要なのは phone をかけたい時ぐらいだから,
119 むしろ,phone を改造して phoned が broadcasting や routing をしながら,
120 特定のユーザがどこにいるか探し回るようにする.
121 さて,そこで皆さんの意見を聞きたいと思います.どうするのが一番良いでしょうか.
122 今考えているのは,1, 2 の機能を持った public domain rwhod を作るといった
123 ところですが,果してそんなことをするのは意味があるのか.4を実現すれば事実上
124 rmap はいらなくなるんじゃないのか.有益な議論をお待ちしています.
125 私は前の mail で次ぎのようなことを書きました.
126 > 御存知のように rwhod はつながるマシンの数が増えると,急激に network 及び
127 > CPU を食いはじめます.また,routing の機能がないため複数のネットワークが
128 > 接続されているような環境ではやはり問題です.東工大ではいままで,gateway
129 > となるマシンの rwhod に手をいれて routing をするようにしていましたが,
131 > 本格的ネットワークを考えると単純に routing を行う今の方法は非現実的です.
132 > そこで,いくつかのアイディアを加藤君と考えました.
133 > 1. broadcast packet は止めて,NFSを利用し /usr/spool/rwho をできる限り
134 > 共有する.どうしても必要なところは point-to-point で routing を行う.
135 > 2. routing する場合に独自のプロトコルにより複数のホストの情報を
137 > 今考えているのは,1, 2 の機能を持った public domain rwhod を作るといった
138 > ところですが,果してそんなことをするのは意味があるのか....
139 今考えていることを,もう少し具体的に説明すると,
140 既存の rwhod は自分のマシンの network configuration を見て
141 自分の属するサブネットワークにはすべて broadcasting で,
142 point-to-point のリンクにはその相手先に対し,自分のマシンの情報のみを
144 私が手を入れた rwhod はそれらに加えて,他のマシンから来た
145 情報を自分の spool に書き込むと同時に,リストとして貯め込んでおき,
146 自分の情報を流す時に同時に,個々のマシンの属するネットワーク以外の
147 すべてのリンクにその情報をリレーするというものです.
148 しかし,この方法だといくら broadcast packet を使ったところで,
149 論理的にはネットワーク全体が完全グラフをなすように packet を
150 流すことになりますし,しかも普段はそういう情報を必要としない
151 場合が多い訳ですから,明らかに供給過剰です.で,これを少しでも
152 軽減することができれば,と考えている訳です.
153 新しい rwhod は,様々なネットワーク上の制約を盛り込めるように,
154 例えば /etc/rwhod.rc のようなファイルからリレーのための configuration
155 を読み込むようにするといいでしょう.そのファイルの中に書かれるべき
156 項目としては,次ぎのようなものが考えられます.
157 1. 自分のマシンの情報をどのマシン,またはどのネットワークに対して
158 送信するか.また,それをローカルファイルに格納するか否か.
159 2. 他のマシンの情報をどのマシン,またはどのネットワークに対して
160 リレーするか.それは packet として受信されるべきものなのか,
161 NFSによってそのマシンの rwhod が書き込んだファイルを
162 読みにいくのか.前者の場合には,さらにその情報をローカル
165 これらに加え,さらに通常は packet を流さずに必要な時だけ,
166 rwhod が他のマシンに対し情報を要求するという機能を付け加えるのも
167 いいかもしれません.このためには,/etc/rwhod.rc の中に
168 4. あるマシンの情報に対する要求があった時にどのマシンに
170 という項目を付け加えるべきでしょう.1,2,4 は実際には統一した
171 フォーマットで記述するのがいいかもしれません.
172 もし,こういう on demand 型のサービスを取り入れると当然 rwho, ruptime, rmap
173 といった client 側にも変更が必要になります.恐らくあるマシンの情報を得るには,
174 といったようなライブラリ関数を用意することになるでしょう.
175 この関数は自分のマシンの rwhod に対してそういう request を
176 行い response を受け取るという単純なものにするのがいいと
177 思います.一方その request を受け取った rwhod はスプールを
178 見てそれが充分新しいものであれば,そこから読み取り,そうでなければ
179 rwhod.rc に書かれたマシンに対し問い合わせることになるでしょう.
180 いや,もうそこまでするのだったら,いっそスプールは全廃して
181 rwhod が on core で情報を管理した方がいいかもしれません.
182 というようなところが今まで考えたところですが,そこでこの前にも書いた
183 疑問に戻ります.果してこんなことをする意味があるのだろうか?
184 phone を hack すれば,それで問題は解決するのではないか?
186 私はこれを今度の meeting で議論してもらいたいとは思っていません.
187 あくまで mail で意見を聞かせて下さい.そうすることで,
188 議論がたまたま meeting に出席した人の中だけでの閉じたもので
190 ところでこの mailing list はいつまで東工大で管理されているのですか.
191 u-tokyo に移した方がいいのではないのですか?