日時：2004年 7月 1日(木) 18:30 から
場所：電気通信大学 情報工学科 西 9号 3階AVホール
新宿駅より京王線，調布駅（特急・準特急で2つ目，15分） 北口下車，
北西方向徒歩12分程度，電気通信大学西地区キャンパスの
南西端にある白い建物; 甲州街道（国道20号線）
下石原交差点の北20メートルに西門あり．
食事：今回もありません．調布駅近辺のハンバーガー，ドーナッツ，牛丼，
その他をご利用ください。電通大の正門のすぐ西にもＭで始まる
ハンバーガー屋が待っています．
◆発表その１
話者：内野 克哉（電気通信大学 情報工学科 渡辺・鈴木研究室卒業生）
題名：快速数式入力
概要：
高速な数式入力方式を考案し実装した。数式を入力する方法として、LaTeX等のバ
ッチ処理方式、Word付属の数式3.0等のキーボードとマウスを併用する方式などがあ
る。これらの方式は一般のテキストを書くエディタと比べて、キーボードの打鍵数が
多い、マウスとキーボードの持ち替えが発生する等の理由で、数学記号を入力するた
めの作業が多く入力速度が遅い。提案方式ではキーボードのキーの1つ1つに数学記号
や数学記号間の移動を対応させており、キーボードのみで数式の入力を行うことがで
きる。これにより打鍵数を少なく抑え、かつマウスとキーボードの持ち替えが発生し
ないため、数式の高速入力システムが実現された。
◆発表その２
話者：原 大輔 （電気通信大学 情報工学専攻 中山研究室 修士1年）
題名：利用者課金のためのウェブサーバ構成法
概要：
ウェブサーバを多数のユーザで共有する場合の利用者課金機構を開発している。
現在のホスティングサービスで用いられている従量課金システムはデータ転送量に
応じたものが主であり、計算機資源使用量が加味されていない。
本システムでは各ユーザの計算機資源使用量を測定し、従量課金の指標として
提供する。
本システムのベースとなるウェブサーバ及び本システムの設計を紹介する。
出席者：45名程度
朝日 啓太，池田 勉，井原 伸介，入江 道生，尾花 智史，大日向 大地，
角田 博保，金山 政利，小林 良岳，阪口 豊，佐藤 喬，繁田 聡一，
篠原 哲洋，鈴木 信吾，関 新之助，多田 好克，中野 宏温，花田 智洋，
春原 真人，東野 敬一郎，間瀬 哲也，丸山 一貴，横田 卓也，渡辺 坦（電通大），
吉田 紀彦（埼玉大），太田 真，山口 文彦（東京理科大），
飯嶋 浩光（つかひやすさ考房），胡 振江，田中 哲朗，林 芳樹，松崎 公紀，
室田 朋樹（東京大），松野 徳大（都立高専）他
◆発表その１
話者：内野 克哉（電気通信大学 情報工学科 渡辺・鈴木研究室卒業生）
題名：快速数式入力
概要：
高速な数式入力方式を考案し実装した。数式を入力する方法として、
LaTeX等のバッチ処理方式、Word付属の数式3.0等のキーボードとマウスを
併用する方式などがある。これらの方式は一般のテキストを書くエディタと
比べて、キーボードの打鍵数が多い、マウスとキーボードの持ち替えが
発生する等の理由で、数学記号を入力するための作業が多く入力速度が遅い。
提案方式ではキーボードのキーの1つ1つに数学記号や数学記号間の移動を
対応させており、キーボードのみで数式の入力を行うことができる。
これにより打鍵数を少なく抑え、かつマウスとキーボードの持ち替えが
発生しないため、数式の高速入力システムが実現された。
質疑応答：
- 数字, +や-の入力は? A. 基本的に数字、+や-などのすでにキーボードに割り振られている数学記号は キーボードウィンドウを経由せずに直接そのキーを入力することで 入力させています。括弧、=等も同様です。キーボードに割り振られていない 数学記号を入力するときにキーボードウィンドウを使うようにしています。 大部分の使用者は自分のキーボードでの数字、+や-等の位置を 把握しているであろうと考え、それらの記号をキーボードウィンドウに 割り振り、再びその位置を覚えさせるのは抵抗があるだろうと 判断したため上記のような入力方法にしました。 - シフト, タブ, なども使わないのか? A. シフトキーは大文字のアルファベットや、前述のすでにキーボードに 割り振られている数学記号を入力する際に使用します。タブキーや コントロールキーは編集領域のカーソル移動、表示の更新、LaTeXソースの 生成など数学記号の入力以外の用途で現在使用しています。 数学記号の入力の際にシフトキーやコントロールキー等を使用することは、 例えばシフトキーを使ってギリシャ記号の大文字を入力させるような使い方が 考えられます。これは大文字のアルファベットの入力方法と同様な入力方法で あるために理解しやすいですが、この入力方法をユーザに知らせる必要があり、 その手間を軽減することが必要です。ヘルプに書くのは当然としても、 キーボードウィンドウにメッセージを表示するなどの工夫を施すと総合的な 入力時間を減らすことができると考えられます。 KLM(Key-stroke Level Model)では、シフトキー等+キーも単なる2打鍵も かかる時間は同じと見なしています。シフトキー等を一切使わず、 層の切り替えとキー入力のみという単純な操作に限定するほうが、 ユーザにとって覚えやすく結果的に速いかもしれません。 シフト等の併用を行うか否かはこれらの研究をする必要があると自分は考えます。 - 「押しやすい」「押しにくい」の判断基準は A. 今のところ、「ホームポジションから近い位置」としか言いようがありません。 私個人の独断と偏見があることは否めません。 [回答補足] 実は、自分がキーをa〜z,;,スペースに限定したのは押しやすさの他にもう一つ 理由があります。キーボードウィンドウはキーボード状にボタンが並んだ ウィンドウですが、これは、直感的にキーボードのどの位置にどの記号が あるかを知ってもらうために設定しました。そのため、 キーボードウィンドウのボタン群はお手元のキーボードと同じ配置に なっていなくてはなりません。 しかし、キーボードの種類は数多く、そのキー配置も多種多様です。 プログラムから、そのキー配置を知る方法は今のところありません。 そのため、キーボード共通のキー配置であると考えられるa〜z,;,スペースのみに キーを限定したという背景もあります。 - 出現頻度は自分ひとりだけで数えたのか A. そうです。 - 大学以上で使われる記号は A. 作成する段階で数式のレベルを高校程度としていましたので、大学以上で 使われる記号は入力できません。 大学以上で使われる記号は、分野別に特化したものが多く、もし入力できるように するのならば、数学記号の使用頻度の調査を再び行う必要があると考えます。 さらにキーボードウィンドウを分野別に用意するか否か等の数学記号の配置の 研究もより深く行う必要があります。 - 67種類を全て覚えるのは大変ではないか? 覚えやすくするためのアプローチも 必要ではないか A. 別に覚える必要はありません。覚えたほうがより早く入力できるだけのことで す。 覚えていなくても入力できるようにキーボードウィンドウがあります。 しかし数学記号を目で探索する必要があり、これはかなり時間がかかります。 より入力を高速にするには、この探索時間を軽減する工夫の研究をする 必要があると考えます。 その工夫は同時に覚えやすくするような工夫にもなると思います。 - 画面表示のトリガは何か A. 現在のところはCtrl-qです。一つの記号を入力するごとに画面表示が更新される のが理想的ですが、現在の計算機の処理速度では現実的ではありません。 妥協案としては、 数式の構造間をカーソルが移動したとき 何文字か入力したとき 一定時間がたったとき 一定時間入力が無かったとき 等が考えられますが、実装には至っていません。 platexとdvioutを利用せずWYSIWYGに編集できるようになれば解決するのですが。 - 作ったものは結局texの補助ツールか A. そうなってしまいました。しかし、新しい数式の入力方式が提案できたと 思います。 - 作成当初の目的は A. 数式入力を容易にしたいというのが当初の目的です。そして他の 数式入力方式と差別化を図るため、入力速度に特化したものを作成しよう ということになりました。 - Microsoftのツールにkey eventsを送る, というやりかたはどうか A. 知識が乏しいので詳しくは答えられないが、もし数式3.0にその方法が可能で あるならば、WYSIWYGに編集が可能となり、さらに作成した数式をそのままWord等に 貼り付けることができるし、LaTeXソースにも変換できるでしょう (その辺のツールはごろごろ落ちている)。 しかし、調査不足で申し訳ありませんが、そのやり方が本当に 可能であるかどうかの見通しはたっていません。 - 既存の数式や今のセッションの中で一部を変更したい場合はどうするのか A. カーソルを移動してバックスペースなりDeleteなりで消去、新たに数式を 入力するという、一般的なエディタのように編集してください。 ただし、検索や置換等の機能はまだ実装していません。 既存の数式(例えばLaTeXで書かれた数式)を読み込むことはまだできません。 字句解析、構文解析、データ構造に変換という処理を記述していません。 - latexを知らない人にとってやりやすいか? 知らないと入力できないのでは ないか A. 現状ではLaTeXソースを編集させる形をとっているので、当然LaTeXを 知らないと入力できないでしょう。 - Unicodeを使って表示させる, というのも可能ではないか A. 可能です。ですが構造を持つ記号をはじめUnicodeで表示できない数学記号は 当然存在し、その場合はLaTeXソースの形になるでしょう。 LaTeXを知らないと入力、編集ができないことは変わらないですが、 ある程度直感的に数式を編集できるようになり、結果入力速度が向上すると 思います。 - かな漢字変換にやらせるのとではどう違うか. もし本手法が有用であるの ならば, なぜかな漢字に使われていないのか A. かな漢字変換では数学記号の他に選択肢が多数存在します。そのためその 選択肢から数学記号を探して選択しなくてはならなくなり、その分打鍵数が 増えてしまいます。何よりその方式は数学記号を入力するための文字列を 覚えていなくてはいけません。 [回答補足] 本手法がかな漢字に使われていないのは、 漢字という記号の数が膨大である 漢字の読みが教育により浸透している かな漢字変換システムが作成されたときはGUIを実現するほどの スペックがなかった ということが考えられます。 漢字の種類は常用漢字だけで2000種類ほどあります。JISコード(JIS X 0208-1978) の時点で登録されている漢字数は6000種類ほどです。旧字や現在使われていない 漢字を含めると50000種類(大漢和辞典)にもなります。これらを早く入力できるから といって意味のない文字列にして覚えるというのは無理がありますし、 キーボードウィンドウに表示しても層の数が膨大になってしまい、探すのも 苦労するでしょう。 逆に、かな漢字変換を数学記号に使わなかった理由としては、 数学記号の画数が少ない 数学記号の読みが一意に普及していない ということが挙げられます。 漢字という記号を手で描くときは多くの画数を必要とします。一方、数学記号は ほとんどが1画、2画で描くことができます。一つの記号にかかる時間が 漢字と数学記号では違います。漢字は読みを入力して変換しても、 つまりかな漢字変換をしても手書きよりも同等以上の速さで入力することが できます。 一方、数学記号は読みを入力して変換すると手書きよりも遅くなってしまいます。 よって、入力速度の目標を板書に追随可能な速度としていましたので かな漢字変換とは別の方式を考える必要がありました。 - Microsoftのツールでもキーのみで入力できると思う. そうしたこととの 比較も必要では. A. 必要だと考えます。今回の入力速度の比較検討は不十分であると感じています。 - 分野によって表示のさせ方がことなる(例えばベクトルなど)ものに対しては どう対応させるか. A. 単純に対応させるには、入力できる数学記号を増やすことです。 そして例えばベクトル では、矢印のベクトルを入力したいなら矢印のベクトルを、直線のベクトルを 入力したいなら直線のベクトルをキーボードウィンドウから探して入力すればよい ということになります。 問題となるのは、それぞれの分野によって数学記号の使用頻度に違いが生じる ということです。分野ごとに最適化したキー配置のキーボードウィンドウを 用意するということが考えられますが、それでは分野ごとにキー配置を 把握しなくてはなりません。自分としては、キー配置はどの分野でも 変わらない配置にして、分野ごとによく使う、もしくは個人的によく使う 数学記号を自由にカスタマイズして登録できるようにすれば対応できると 考えています。 しかし、どの手法が最良な解決策になるかは比較検討を重ねる必要があり、 今後の研究課題の一つとして考えられます。
◆発表その２
話者：原 大輔 （電気通信大学 情報工学専攻 中山研究室 修士1年）
題名：利用者課金のためのウェブサーバ構成法
概要：
ウェブサーバを多数のユーザで共有する場合の利用者課金機構を開発している。
現在のホスティングサービスで用いられている従量課金システムはデータ転送量に
応じたものが主であり、計算機資源使用量が加味されていない。
本システムでは各ユーザの計算機資源使用量を測定し、従量課金の指標として提供する。
本システムのベースとなるウェブサーバ及び本システムの設計を紹介する。
質疑応答：
Q. なぜURIからusernameを取り出すようにしたのか? apacheから所有者を見る ことができるのでは. A. サーバプロセスは初期状態で root 権限で動作しており、リクエストを受け付けて 初めてそのユーザの権限に変更するため。 --- Q. wait4で得られる情報はどういうもの? それは直接の子プロセスだけか? A. CPU 時間、メモリ、ディスクなどの使用量である。 具体的には rusage 構造体を取得できる。 (rusage 構造体のメンバについては man 2 getrusage を参照されたい) きちんと wait で待てば子孫の累計の情報が取得できる。 --- Q. 時間の計測はcpu timeぐらいだけで何とかできないか A. リクエストを受け付けた時とレスポンスを返す時にそれぞれ時刻とユーザ名を 記録しておけば大まかな CPU 時間を知ることができるが、以下の問題がある。 * リクエストを受け付けてからレスポンスを返すまでそのプロセスが CPU を独占 しているわけではないので、正確な CPU 時間ではない。 課金に用いるため情報の正確性が求められる。 * CPU 以外の情報が分からない。 --- Q. 死ぬまではデータを取れないのか? へたをすると過大請求をしてしまうのでは ないか. そうだとしたら定期的にlogを吐き出させる方が良いのではないか. A. #apachectl graceful というコマンドを発行すると、サーバプロセスは現在の 接続が終了次第 exit() し、新たなプロセスが fork() される。 つまり接続を切断することなくそれまでの計算機資源使用量を取得することができる。 このコマンドを定期的に発行することで障害時などにも対応できる。 --- Q. apacheはnobodyでは動かさないのではないか. groupの適切な設定や, またapache2を使うことで回避可能ではないか. A. 確かに通常はユーザ apache(RedHat系 Linux)、www-data(Debian)といった ログインシェルを持たない Apache 専用ユーザで動作させる。 発表ではそれらを総称した意味で nobody とした。 ちなみに Apache のデフォルトは nobody である。 Apache2 では Perchild という MPM(Multi Processing Module)を使うことで バーチャルホスト毎に別のユーザが指定可能である。 しかし、Perchild は未だ実験段階にあり実用的とは言えない。 (http://httpd.apache.org/docs-2.1/ja/mod/perchild.html 参照) 本システムで対象とするのはバーチャルホストを使用せず、多数(100, 1000)の ユーザがユーザディレクトリを使って一つのサーバを共有するものである。 バーチャルホストはユーザディレクトリに比べてコストが大きく、 多数のユーザそれぞれにホストを割り当てるのは難しい。 --- Q. 請求する料金を利用者に納得させるためには, 結構多量のデータを開示する ようにしないと駄目ではないか. DoS攻撃を受けた場合の対策(request shapingなど)も必要のはず A. 本システムは実際の課金モデルには言及しない。 （サイト開設者に課金するのか、サイト閲覧者に課金するのかも含めて） 課金の指標となりうるデータをできるだけ多く提供するのが目的である。 DoS 攻撃に対しては同一 IP からの接続数制御などを行って対処する。 (複数の Apache モジュールが存在する) しかし、DoS 攻撃の影響は本システム特有の問題ではなく、現在のデータ転送量 のみによる従量課金にも同じことが言える。 --- Q. VMのレベルでの測定管理ができるのではないか A. VM 一つに対してホストを一つ割り当てるというのは、ユーザ毎に バーチャルホストを割り当てるよりもさらにコストが大きいので、 やはり本システムが対象とする多数のユーザがいる環境には適さないと考えられる。 --- Q. OSの持つaccounting情報が, 特にcgiに対して使えるのではないか A. 各ユーザが使ったプログラム毎の計算機資源の量が分かれば使える。 本システムを使った上で、httpd が使った計算機資源の量をユーザ毎に取得する。 本システムを使わず、suEXEC などを使ってこれをやると CGI のアカウンティング 情報しか取れない。 厳密なアカウンティングのためには CGI を含めた httpd 実行全ての部分での アカウンティング情報が必要である。 --- Q. setuid & chrootすると, 例えばperlのlibraryが見えない, などといった ことが発生してしまわないか A. 各ユーザディレクトリ内に仮想ディレクトリツリーを形成しており、 必要なバイナリ、ライブラリなどはマウントしている。 --- Q. ベースとするウェブサーバで発生したoverheadはどの程度だったのか. ユーザの待ち時間の点でのoverheadは. A. 10KB のファイルを連続10000回リクエストするといった実験をしたところ 完了時間で30倍程度のオーバヘッドがあった。 前述のようにスループットは落ちたが、それを体感するのはアクセスが 増加した時である。 以上の性能低下はベースとなるウェブサーバでサーバプロセスをリクエスト毎に 終了していたためである。 本システムではプロセスを使いまわすので性能は改善される見込みである。