src/cmd/tcs/ex2.utf - plan9 - Git at Google

 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 に移した方がいいのではないのですか？
	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 に移した方がいいのではないのですか？