diff options
author | wkj <devnull@localhost> | 2004-04-21 01:15:41 +0000 |
---|---|---|
committer | wkj <devnull@localhost> | 2004-04-21 01:15:41 +0000 |
commit | a31db67d14c0e50353eac3db342f3c969cabdf76 (patch) | |
tree | 0cebd9a65bab940355f5be0751f53238366555d7 /src/cmd/tcs/ex2.utf | |
parent | ba03b8910dd07511378e6f1007faf0539ed25598 (diff) | |
download | plan9port-a31db67d14c0e50353eac3db342f3c969cabdf76.tar.gz plan9port-a31db67d14c0e50353eac3db342f3c969cabdf76.tar.bz2 plan9port-a31db67d14c0e50353eac3db342f3c969cabdf76.zip |
Add tcs; it compiles in my world, but I haven't tried it in Russ's yet.
Diffstat (limited to 'src/cmd/tcs/ex2.utf')
-rw-r--r-- | src/cmd/tcs/ex2.utf | 192 |
1 files changed, 192 insertions, 0 deletions
diff --git a/src/cmd/tcs/ex2.utf b/src/cmd/tcs/ex2.utf new file mode 100644 index 00000000..99d3e89c --- /dev/null +++ b/src/cmd/tcs/ex2.utf @@ -0,0 +1,192 @@ +From dmr Thu Jan 30 17:00:03 EST 1992 +誠に申し訳ありませんが、MH front end はあと1週間だけ待って下さい。 +新しい xterm のために vtwin の変更が必要となって、それにちょっと +手間取ってしまいました。まだもう1つ直したい bug があるのですが +もう今日は時間がありません。 +拝啓 新緑の候、ますますご清祥のこととお喜び申し上げます。 +さて、斎藤信男先生は4月1日をもちまして、慶応義塾大学理工学部教 +授に御昇任なられました。そこで、日頃斎藤先生にお世話になっている +私達が斎藤先生に お祝いを申し上げるためのささやかな 祝宴を企画致 +しました。当日は 斎藤研究室 OB/OG の方々、斎藤研究室現役の学生、 +また、斎藤先生ゆかりの方々が集まり、斎藤先生を囲んで楽しいひとと +きを過ごしたいと考えております。ご家族、御友人おさそいあわせのう +え御列席下さるようお願い申し上げます。 +おそれいりますが、ご出席の確認を下記連絡先に電話または電子メール +にてご連絡下さるようお願い申し上げます。 + 敬具 + 「斎藤信男教授を囲む会」 +日時: 昭和62年4月24日(金) 18:00 より +場所: 新橋第一ホテル「レストランクラレット」 + 電話; 03-501-4411 +会費: 1万5千円 (当日記念品代1口5千円を別に御用意下さい。) + ただし、学生料金は別途設定してありますので御安心! +連絡先:中村 修 osamu@keio.junet + 電話 044-63-9137 (斎藤研究室直通) + 電話 03-704-4715 (中村自宅) + 幹事代表 村井 純、 中村 修 +拝啓 新緑の候、ますますご清祥のこととお喜び申し上げます。 +さて、斎藤信男先生は4月1日をもちまして、慶応義塾大学理工学部教 +授に御昇任なられました。そこで、日頃斎藤先生にお世話になっている +私達が斎藤先生に お祝いを申し上げるためのささやかな 祝宴を企画致 +しました。当日は 斎藤研究室 OB/OG の方々、斎藤研究室現役の学生、 +また、斎藤先生ゆかりの方々が集まり、斎藤先生を囲んで楽しいひとと +きを過ごしたいと考えております。ご家族、御友人おさそいあわせのう +え御列席下さるようお願い申し上げます。 +おそれいりますが、ご出席の確認を下記連絡先に電話または電子メール +にてご連絡下さるようお願い申し上げます。 + 敬具 + 「斎藤信男教授を囲む会」 +日時: 昭和62年4月24日(金) 18:00 より +場所: 新橋第一ホテル「レストランクラレット」 + 電話; 03-501-4411 +会費: 1万5千円 (当日記念品代1口5千円を別に御用意下さい。) + ただし、学生料金は別途設定してありますので御安心! +連絡先:中村 修 osamu@keio.junet + 電話 044-63-9137 (斎藤研究室直通) + 電話 03-704-4715 (中村自宅) + 幹事代表 村井 純、 中村 修 +JUS幹事の皆様: +4月10日の幹事会でお話した、次のような講演についての件ですが、 + 発内容:Macintosh IIへのUNIXの移植 + 発 者:米国UniSoftのエンジニア + 発時間:1時間(幹事会において決まった時間です) + 発当人からABSTRACTが届きました。このような内容での話でよけれ +ば、来日するがどうだろう?との問い合わせがあったのですが、皆様いかがでしょうか? +皆様の御意見を伺ったうえで、本当に来てもらうかどうか当人に連絡したいと思います。 +(交通費、宿泊費などはJUSから出す必要はありません) +御返答、よろしくお願いいたします。 + DCL 坂本 文 +JUS幹事の皆様: +4月10日の幹事会でお話した、次のような講演についての件ですが、 + 発内容:Macintosh IIへのUNIXの移植 + 発 者:米国UniSoftのエンジニア + 発時間:1時間(幹事会において決まった時間です) + 発当人からABSTRACTが届きました。このような内容での話でよけれ +ば、来日するがどうだろう?との問い合わせがあったのですが、皆様いかがでしょうか? +皆様の御意見を伺ったうえで、本当に来てもらうかどうか当人に連絡したいと思います。 +(交通費、宿泊費などはJUSから出す必要はありません) +御返答、よろしくお願いいたします。 + DCL 坂本 文 + 次回のjus幹事会は下記の場所で行います。 +日時 5/8(金)午後6時 +場所 (株)アスキ―、FFFビル、7F役員会議室 +地図 + 至赤坂 +国道246号(青山通り) + | |*(地下鉄表参道B3出口) + | | (ラ―メン屋) +紀ノ国屋| |出光GS 天下一 + | | 住 大 F* + | | 友 仁 F + | | 南 堂 F + 至渋谷 青 ビ ビ + 山 ル ル + ビ + ル +(1)地下鉄表参道駅下車、B3の出口を出る。 +(2)青山通りを渋谷方面へ歩く +(3)初めての信号(角が出光GS)を右へ曲る +(4)約500M歩き(信号4つ目)、T字路の交差点の右側 +(5)FFFビルの7F +PS.当日14:40着の便で成田に帰って来ますので、少し遅れるかもしれません + が先に始めて下さい。 + この間の集りでマーク・シートの読み取りのsoftの話題があったと思うので +すが,「インタフェース5月号」の新製品紹介の欄で,ANK character の読み取りの +softの紹介があったように思います。 + ただ,その雑誌がいま,手元にないので詳しくはわかりませんが,調べてみ +ます。 +一部の人は知っていると思いますが,現在 rmap のPD化を進めています. +余分な機能をそぎ落し,一通り動くようになりました.あと,2,3 +新たな機能を追加する予定ですが,問題はその前提となる rwhod にあります. +御存知のように rwhod はつながるマシンの数が増えると,急激に network 及び +CPU を食いはじめます.また,routing の機能がないため複数のネットワークが +接続されているような環境ではやはり問題です.東工大ではいままで,gateway +となるマシンの rwhod に手をいれて routing をするようにしていましたが, +その場しのぎのいい加減なやり方だったので,4月にネットワークの接続形態が +変って以来,2重に packet を流していたことが判明しました.昨日急いで +直しましたが,それまでネットワークは collision の嵐だった訳です. +たかだか30台のネットワークでこの有様ですから,何百,何千という +本格的ネットワークを考えると単純に routing を行う今の方法は非現実的です. +そこで,いくつかのアイディアを加藤君と考えました. +1. broadcast packet は止めて,NFSを利用し /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 を作るといった +ところですが,果してそんなことをするのは意味があるのか.4を実現すれば事実上 +rmap はいらなくなるんじゃないのか.有益な議論をお待ちしています. +私は前の mail で次ぎのようなことを書きました. +> 御存知のように rwhod はつながるマシンの数が増えると,急激に network 及び +> CPU を食いはじめます.また,routing の機能がないため複数のネットワークが +> 接続されているような環境ではやはり問題です.東工大ではいままで,gateway +> となるマシンの rwhod に手をいれて routing をするようにしていましたが, +> ....,何百,何千という +> 本格的ネットワークを考えると単純に routing を行う今の方法は非現実的です. +> そこで,いくつかのアイディアを加藤君と考えました. +> 1. broadcast packet は止めて,NFSを利用し /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 として受信されるべきものなのか, + NFSによってそのマシンの 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 に移した方がいいのではないのですか? + |