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