commit 061180242c22995ef05c4504633965b338b5b928
parent 4fd4b8a714791627f4f7838a93a06df75d6c761c
Author: Matsuda Kenji <info@mtkn.jp>
Date: Thu, 19 Dec 2024 21:00:54 +0900
revise
Diffstat:
7 files changed, 58 insertions(+), 54 deletions(-)
diff --git a/data/weblog b/data/weblog
@@ -224,3 +224,18 @@
1734447600 /computer/9p.html
1734447600 /computer/9p.html
1734447600 /computer/9p.html
+1734534000 /index.html
+1734534000 /computer/9p.html
+1734534000 /computer/9p.html
+1734534000 /computer/9p.html
+1734534000 /computer/9p.html
+1734534000 /computer/9p.html
+1734534000 /computer/9p.html
+1734534000 /computer/9p.html
+1734534000 /computer/9p.html
+1734534000 /computer/9p.html
+1734534000 /computer/9p.html
+1734534000 /computer/9p.html
+1734534000 /computer/9p.html
+1734534000 /computer/9p.html
+1734534000 /computer/9p.html
diff --git a/man/computer/9p.html b/man/computer/9p.html
@@ -16,12 +16,7 @@ Plan9というOSはネットワークを介して複数のコンピュータを
この9Pもローカルだけでなくネットワーク越しに使うことを前提にしている。\
</p>
-<p>
-便利そうなのでGo言語で実装してみた。
-</p>
-
-<h2>9Pプロトコル</h2>
-<h3>概要</h3>
+<h2>プロトコルの概要</h2>
<p>
9Pの通信ではクライアントがサーバーに対してリクエストを送り、サーバーがそれに\
対してリプライを返すことを繰り返す。\
@@ -56,7 +51,7 @@ Twriteに対してRwrite等である。\
実際はバイナリの通信だが、ログとして見易いように変換してある。\
また、先頭にくるメッセージサイズは省略してある。\
この例では、サーバーのルートディレクトリにある<code>hello</code>という\
-ファイルの内容を読みこんでいる。:\
+ファイルの内容を読みこんでいる:\
</p>
<pre><code>\
<-- Tversion Tag 65535 msize 8192 version '9P2000'
@@ -95,7 +90,7 @@ Tversionのタグは<code>65535</code>と決められている。\
<code>fid</code>はコネクションにおいてファイルと紐付けられる整数で、\
Unixにおけるファイルディスクリプタのようなものである。\
ファイルの読み書きはこの<code>fid</code>を使って行われる。\
-サーバーからの<code>Rattach</code>にはルートディレクトリの\
+サーバーからのRattachにはルートディレクトリの\
<code>qid</code>が含まれる。\
これはサーバー上でファイルを一意に識別するもので、\
Unixにおけるinodeに相当するものである。\
@@ -125,7 +120,7 @@ Treadを使って内容を読む。\
最後に、必要なくなった<code>fid</code>はTclunkで捨てる。\
</p>
-<h3>List of all Message Types</h3>
+<h2>List of all Message Types</h2>
<table>
<tr>
@@ -236,8 +231,8 @@ Unixのinodeに相当するものである。\
<p>
9PサーバーはTattachメッセージを受けとると、\
認証サーバーとのコネクションを確立する。\
-その後<code>Rattach</code>メッセージで<code>afid</code>という\
-特殊なFidをクライアントに返す。\
+その後Rattachメッセージで<code>afid</code>という\
+特殊な<code>fid</code>をクライアントに返す。\
クライアントからこの<code>afid</code>に対して読み書きする命令が届くと、\
9Pサーバーはこの読み書きを認証サーバーとのコネクションに横流しする。\
つまりクライアントはこの<code>afid</code>を通じて認証サーバーと\
@@ -264,18 +259,19 @@ Tattachで得られた<code>fid</code>は、\
Twalkメッセージによりファイルツリーを辿るための起点として利用でき、\
このとき辿った先のファイルを示す<code>fid</code>が生成される。\
これ以外の方法で<code>fid</code>が増えることはない。\
-つまり、サーバーはひとつのコネクションのなかで、から\
+つまり、サーバーはひとつのコネクションのなかで、ルートディレクトリから\
派生した<code>fid</code>を追跡することで、クライアントを区別できる。\
</p>
<h2>メッセージ詳細</h2>
<p>
-各メッセージの詳細を書く。\
それぞれ最初にメッセージの形式を書く。\
<code><i>field</i>[<i>n</i>]</code>は<code><i>field</i></code>\
という名前の<i>n</i>バイトのデータを表す(<i>n</i>は整数)。\
-また、括弧の中が整数ではなくsになっている場合、そのフィールドは\
-文字列のデータで、その前に文字列の長さを示す2バイトのデータが先行する。\
+また、括弧の中が整数ではなく<code>s</code>になっている場合、そのフィールドは\
+文字列のデータで、その前に文字列の長さを示す2バイトの整数が先行する。\
+また、メッセージ名のフィールド(<code>Tversion</code>等)にはメッセージの種類を\
+表す1バイトのenumが来る。
</p>
<h3>version</h3>
<p>
@@ -313,7 +309,7 @@ size[4] Rattach tag[2] qid[13]
先に<code>auth</code>メッセージで認証を済ませておき、\
<code>attach</code>メッセージの<code>afid</code>に、\
先程使用した<code>afid</code>をセットする。\
-サーバーはこの<cdoe>afid</code>に紐付いている認証サーバーに\
+サーバーはこの<code>afid</code>に紐付いている認証サーバーに\
クライアントが認証済みであるかを確認し、\
認証済みであればルートディレクトリの<code>qid</code>を返す。\
サーバーが複数のファイルツリーを公開している場合、\
@@ -323,7 +319,7 @@ size[4] Rattach tag[2] qid[13]
<code>auth</code>メッセージは認証サーバーとやりとりするための\
<code>fid</code>である<code>afid</code>を要求する。\
この<code>afid</code>を読み書きすることで\
-認証サーバーとやりとりをし、自身を身分を証明する。\
+認証サーバーとやりとりをし、自身の身分を証明する。\
認証が済んだらこの<code>afid</code>をセットした\
<code>attach</code>メッセージを送る。\
</p>
@@ -338,8 +334,7 @@ size[4] Rerror tag[2] ename[s]
<p>
クライアントからの要求に対して、なにかエラーがおきたときに\
そのエラーを返すために使われる。\
-そのためサーバーからクライアントへの<code>Rerror</code>はあるが\
-逆向きのTメッセージはない。\
+<code>Terror</code>はない。\
</p>
<h3>flush</h3>
diff --git a/man/index.html b/man/index.html
@@ -9,6 +9,7 @@
<h2>更新履歴</h2>
<a href="/rss.xml">RSS</a>
<ul>
+<li>2024-01-19 <a href="/computer/9p.html">9P</a></li>
<li>2024-12-11 <a href="/journal/posts/20241211.html">きのかわ弦楽合奏団 第5回コミュニティコンサート</a></li>
<li>2024-12-02 <a href="/journal/posts/20241202.html">椅子作った</a></li>
<li>2024-10-10 <a href="/kitchen/recipe/mapo_tofu.html">麻婆豆腐</a></li>
diff --git a/pub/computer/9p.html b/pub/computer/9p.html
@@ -32,12 +32,7 @@
<p>
Plan9というOSはネットワークを介して複数のコンピュータを繋いで使うように設計されているので、この9Pもローカルだけでなくネットワーク越しに使うことを前提にしている。</p>
-<p>
-便利そうなのでGo言語で実装してみた。
-</p>
-
-<h2>9Pプロトコル</h2>
-<h3>概要</h3>
+<h2>プロトコルの概要</h2>
<p>
9Pの通信ではクライアントがサーバーに対してリクエストを送り、サーバーがそれに対してリプライを返すことを繰り返す。クライアントからのリクエストをTメッセージ、サーバーからのリプライをRメッセージと言う。Tメッセージにはファイルにアクセスするための色々なものが用意されている。例えばファイルを開くためのTopenや、開いたファイルに書き込むためのTwrite等である。それぞれのTメッセージには対応するRメッセージがある。Topenに対してRopen、Twriteに対してRwrite等である。</p>
<p>
@@ -45,7 +40,7 @@ Plan9というOSはネットワークを介して複数のコンピュータを
<p>
各メッセージは4バイトの整数から始まる。これは、この4バイトを含むメッセージの長さをバイト単位で示したものである。次にメッセージの種類を記述する1バイトのデータが来る。次はメッセージのタグである。クライアントはサーバーからの返事を待たずに別のメッセージを送れるので、サーバーからのRメッセージがどのTメッセージに対する返事なのかを識別する必要がある。そのために使うのがタグである。クライアントがTメッセージを送る際にタグを付け、サーバーはそれに対するRメッセージに同じタグを付ける。その後ろには、メッセージの種類によって固有の情報が付けられる。</p>
<p>
-以下は実際の9P通信のログである。実際はバイナリの通信だが、ログとして見易いように変換してある。また、先頭にくるメッセージサイズは省略してある。この例では、サーバーのルートディレクトリにある<code>hello</code>というファイルの内容を読みこんでいる。:</p>
+以下は実際の9P通信のログである。実際はバイナリの通信だが、ログとして見易いように変換してある。また、先頭にくるメッセージサイズは省略してある。この例では、サーバーのルートディレクトリにある<code>hello</code>というファイルの内容を読みこんでいる:</p>
<pre><code><-- Tversion Tag 65535 msize 8192 version '9P2000'
--> Rversion Tag 65535 msize 8192 version '9P2000'
<-- Tattach Tag 0 fid 0 afid -1 uname kenji aname
@@ -68,7 +63,7 @@ Plan9というOSはネットワークを介して複数のコンピュータを
<p>
まず最初にクライアントがサーバーに対してTversionを送り、プロトコルのバージョンと、メッセージの最大サイズを交渉する。Tversionのタグは<code>65535</code>と決められている。<code>msize</code>の8192はメッセージの最大サイズ(バイト)で、<code>version</code>の9P2000がプロトコルのバージョンである。サーバーからRversionで同じ<code>msize</code>と<code>version</code>が返ってきたのでこのサイズとバージョンで以降の通信を行う。</p>
<p>
-次のTattachで、クライアントがサーバーにルートディレクトリの<code>fid</code>を要求する。<code>afid</code>以降は認証用の情報である(後述)。<code>fid</code>はコネクションにおいてファイルと紐付けられる整数で、Unixにおけるファイルディスクリプタのようなものである。ファイルの読み書きはこの<code>fid</code>を使って行われる。サーバーからの<code>Rattach</code>にはルートディレクトリの<code>qid</code>が含まれる。これはサーバー上でファイルを一意に識別するもので、Unixにおけるinodeに相当するものである。以上でサーバーに繋いでセッションを確立できた。</p>
+次のTattachで、クライアントがサーバーにルートディレクトリの<code>fid</code>を要求する。<code>afid</code>以降は認証用の情報である(後述)。<code>fid</code>はコネクションにおいてファイルと紐付けられる整数で、Unixにおけるファイルディスクリプタのようなものである。ファイルの読み書きはこの<code>fid</code>を使って行われる。サーバーからのRattachにはルートディレクトリの<code>qid</code>が含まれる。これはサーバー上でファイルを一意に識別するもので、Unixにおけるinodeに相当するものである。以上でサーバーに繋いでセッションを確立できた。</p>
<p>
次にTwalkで目的のファイル(<code>hello</code>)までファイルツリーを辿る。ここでは起点として先程得られたルートディレクトリ(<code>fid = 1</code>)を起点として、このディレクトリ内の<code>hello</code>ファイルを要求して<code>fid = 2</code>を割り当てようとしている。サーバーはルートディレクトリ内に要求されたファイルが見付かったので、そのファイルの<code>qid</code>を返す。</p>
<p>
@@ -78,7 +73,7 @@ Plan9というOSはネットワークを介して複数のコンピュータを
<p>
最後に、必要なくなった<code>fid</code>はTclunkで捨てる。</p>
-<h3>List of all Message Types</h3>
+<h2>List of all Message Types</h2>
<table>
<tr>
@@ -168,18 +163,19 @@ Plan9というOSはネットワークを介して複数のコンピュータを
9Pにはクライアントの認証が組込まれていない。もともとはあったようだが、認証のアルゴリズムに欠陥が見付かったりすればいちいちコードを修正してコンパイルしなおさなければいけないうえ、9Pプロトコル自体も変更しないといけないので、外部に切りだすことになった。認証に必要なやりとりは認証サーバーとクライアントが行い、9Pサーバーは認証が成功したかどうかの情報を認証サーバーに確認することでクライアントの確認を行う。
</p>
<p>
-9PサーバーはTattachメッセージを受けとると、認証サーバーとのコネクションを確立する。その後<code>Rattach</code>メッセージで<code>afid</code>という特殊なFidをクライアントに返す。クライアントからこの<code>afid</code>に対して読み書きする命令が届くと、9Pサーバーはこの読み書きを認証サーバーとのコネクションに横流しする。つまりクライアントはこの<code>afid</code>を通じて認証サーバーと直接やりとりができる。クライアントはユーザー名やパスワード等(パスワード認証の場合)の情報を<code>afid</code>に書き込んで認証する。このように認証をプロトコル自体から切り離すことで、認証に関するバグが見付かったとしても、認証サーバーを修正するだけでいい。また、より強力な認証システムを組み込むのも楽である。
+9PサーバーはTattachメッセージを受けとると、認証サーバーとのコネクションを確立する。その後Rattachメッセージで<code>afid</code>という特殊な<code>fid</code>をクライアントに返す。クライアントからこの<code>afid</code>に対して読み書きする命令が届くと、9Pサーバーはこの読み書きを認証サーバーとのコネクションに横流しする。つまりクライアントはこの<code>afid</code>を通じて認証サーバーと直接やりとりができる。クライアントはユーザー名やパスワード等(パスワード認証の場合)の情報を<code>afid</code>に書き込んで認証する。このように認証をプロトコル自体から切り離すことで、認証に関するバグが見付かったとしても、認証サーバーを修正するだけでいい。また、より強力な認証システムを組み込むのも楽である。
</p>
<h2>コネクションの共有</h2>
<p>
クライアントはサーバーと<code>version</code>メッセージを交すことでコネクションを確立する。コネクションの確立からの一連のやりとりをセッションという。ひとつのコネクションは複数のクライアントが共有できる。</p>
<p>
-クライアントはTauthまたはTattachメッセージによりサーバーに<code>fid</code>を要求できる。このうちTauthにより得られた<code>fid</code>は認証以外には使えない。Tattachで得られた<code>fid</code>は、Twalkメッセージによりファイルツリーを辿るための起点として利用でき、このとき辿った先のファイルを示す<code>fid</code>が生成される。これ以外の方法で<code>fid</code>が増えることはない。つまり、サーバーはひとつのコネクションのなかで、から派生した<code>fid</code>を追跡することで、クライアントを区別できる。</p>
+クライアントはTauthまたはTattachメッセージによりサーバーに<code>fid</code>を要求できる。このうちTauthにより得られた<code>fid</code>は認証以外には使えない。Tattachで得られた<code>fid</code>は、Twalkメッセージによりファイルツリーを辿るための起点として利用でき、このとき辿った先のファイルを示す<code>fid</code>が生成される。これ以外の方法で<code>fid</code>が増えることはない。つまり、サーバーはひとつのコネクションのなかで、ルートディレクトリから派生した<code>fid</code>を追跡することで、クライアントを区別できる。</p>
<h2>メッセージ詳細</h2>
<p>
-各メッセージの詳細を書く。それぞれ最初にメッセージの形式を書く。<code><i>field</i>[<i>n</i>]</code>は<code><i>field</i></code>という名前の<i>n</i>バイトのデータを表す(<i>n</i>は整数)。また、括弧の中が整数ではなくsになっている場合、そのフィールドは文字列のデータで、その前に文字列の長さを示す2バイトのデータが先行する。</p>
+それぞれ最初にメッセージの形式を書く。<code><i>field</i>[<i>n</i>]</code>は<code><i>field</i></code>という名前の<i>n</i>バイトのデータを表す(<i>n</i>は整数)。また、括弧の中が整数ではなく<code>s</code>になっている場合、そのフィールドは文字列のデータで、その前に文字列の長さを示す2バイトの整数が先行する。また、メッセージ名のフィールド(<code>Tversion</code>等)にはメッセージの種類を表す1バイトのenumが来る。
+</p>
<h3>version</h3>
<p>
プロトコルのバージョンを交渉すし、コネクションを確立する。
@@ -203,9 +199,9 @@ size[4] Tattach tag[2] fid[4] afid[4] uname[s] aname[s]
size[4] Rattach tag[2] qid[13]
</code></pre>
<p>
-<code>attach</code>メッセージはサーバーのルートディレクトリを要求し、<code>fid</code>を割り当てる。認証が必要なサーバーであれば、先に<code>auth</code>メッセージで認証を済ませておき、<code>attach</code>メッセージの<code>afid</code>に、先程使用した<code>afid</code>をセットする。サーバーはこの<cdoe>afid</code>に紐付いている認証サーバーにクライアントが認証済みであるかを確認し、認証済みであればルートディレクトリの<code>qid</code>を返す。サーバーが複数のファイルツリーを公開している場合、<code>aname</code>で指定する。</p>
+<code>attach</code>メッセージはサーバーのルートディレクトリを要求し、<code>fid</code>を割り当てる。認証が必要なサーバーであれば、先に<code>auth</code>メッセージで認証を済ませておき、<code>attach</code>メッセージの<code>afid</code>に、先程使用した<code>afid</code>をセットする。サーバーはこの<code>afid</code>に紐付いている認証サーバーにクライアントが認証済みであるかを確認し、認証済みであればルートディレクトリの<code>qid</code>を返す。サーバーが複数のファイルツリーを公開している場合、<code>aname</code>で指定する。</p>
<p>
-<code>auth</code>メッセージは認証サーバーとやりとりするための<code>fid</code>である<code>afid</code>を要求する。この<code>afid</code>を読み書きすることで認証サーバーとやりとりをし、自身を身分を証明する。認証が済んだらこの<code>afid</code>をセットした<code>attach</code>メッセージを送る。</p>
+<code>auth</code>メッセージは認証サーバーとやりとりするための<code>fid</code>である<code>afid</code>を要求する。この<code>afid</code>を読み書きすることで認証サーバーとやりとりをし、自身の身分を証明する。認証が済んだらこの<code>afid</code>をセットした<code>attach</code>メッセージを送る。</p>
<h3>error</h3>
<p>
@@ -214,7 +210,7 @@ size[4] Rattach tag[2] qid[13]
<pre><code>size[4] Rerror tag[2] ename[s]
</code></pre>
<p>
-クライアントからの要求に対して、なにかエラーがおきたときにそのエラーを返すために使われる。そのためサーバーからクライアントへの<code>Rerror</code>はあるが逆向きのTメッセージはない。</p>
+クライアントからの要求に対して、なにかエラーがおきたときにそのエラーを返すために使われる。<code>Terror</code>はない。</p>
<h3>flush</h3>
<p>
diff --git a/pub/index.html b/pub/index.html
@@ -33,6 +33,7 @@
<h2>更新履歴</h2>
<a href="/rss.xml">RSS</a>
<ul>
+<li>2024-01-19 <a href="/computer/9p.html">9P</a></li>
<li>2024-12-11 <a href="/journal/posts/20241211.html">きのかわ弦楽合奏団 第5回コミュニティコンサート</a></li>
<li>2024-12-02 <a href="/journal/posts/20241202.html">椅子作った</a></li>
<li>2024-10-10 <a href="/kitchen/recipe/mapo_tofu.html">麻婆豆腐</a></li>
diff --git a/pub/rss.xml b/pub/rss.xml
@@ -5,14 +5,14 @@
<description>ウェブページの更新履歴</description>
<language>ja-jp</language>
<link>https://www.mtkn.jp</link>
-<lastBuildDate>Wed, 18 Dec 2024 20:43:17 +0900</lastBuildDate>
-<pubDate>Wed, 18 Dec 2024 20:43:17 +0900</pubDate>
+<lastBuildDate>Thu, 19 Dec 2024 21:00:44 +0900</lastBuildDate>
+<pubDate>Thu, 19 Dec 2024 21:00:44 +0900</pubDate>
<docs>https://www.rssboard.org/rss-specification</docs>
<item>
<title>9P</title>
<link>https://www.mtkn.jp/computer/9p.html</link>
<guid>https://www.mtkn.jp/computer/9p.html</guid>
-<pubDate>Wed, 18 Dec 2024 00:00:00 +0900</pubDate>
+<pubDate>Thu, 19 Dec 2024 00:00:00 +0900</pubDate>
<description><![CDATA[<h1>9P</h1>
<time>2024-10-27</time>
<h2>はじめに</h2>
@@ -23,12 +23,7 @@
<p>
Plan9というOSはネットワークを介して複数のコンピュータを繋いで使うように設計されているので、この9Pもローカルだけでなくネットワーク越しに使うことを前提にしている。</p>
-<p>
-便利そうなのでGo言語で実装してみた。
-</p>
-
-<h2>9Pプロトコル</h2>
-<h3>概要</h3>
+<h2>プロトコルの概要</h2>
<p>
9Pの通信ではクライアントがサーバーに対してリクエストを送り、サーバーがそれに対してリプライを返すことを繰り返す。クライアントからのリクエストをTメッセージ、サーバーからのリプライをRメッセージと言う。Tメッセージにはファイルにアクセスするための色々なものが用意されている。例えばファイルを開くためのTopenや、開いたファイルに書き込むためのTwrite等である。それぞれのTメッセージには対応するRメッセージがある。Topenに対してRopen、Twriteに対してRwrite等である。</p>
<p>
@@ -36,7 +31,7 @@ Plan9というOSはネットワークを介して複数のコンピュータを
<p>
各メッセージは4バイトの整数から始まる。これは、この4バイトを含むメッセージの長さをバイト単位で示したものである。次にメッセージの種類を記述する1バイトのデータが来る。次はメッセージのタグである。クライアントはサーバーからの返事を待たずに別のメッセージを送れるので、サーバーからのRメッセージがどのTメッセージに対する返事なのかを識別する必要がある。そのために使うのがタグである。クライアントがTメッセージを送る際にタグを付け、サーバーはそれに対するRメッセージに同じタグを付ける。その後ろには、メッセージの種類によって固有の情報が付けられる。</p>
<p>
-以下は実際の9P通信のログである。実際はバイナリの通信だが、ログとして見易いように変換してある。また、先頭にくるメッセージサイズは省略してある。この例では、サーバーのルートディレクトリにある<code>hello</code>というファイルの内容を読みこんでいる。:</p>
+以下は実際の9P通信のログである。実際はバイナリの通信だが、ログとして見易いように変換してある。また、先頭にくるメッセージサイズは省略してある。この例では、サーバーのルートディレクトリにある<code>hello</code>というファイルの内容を読みこんでいる:</p>
<pre><code><-- Tversion Tag 65535 msize 8192 version '9P2000'
--> Rversion Tag 65535 msize 8192 version '9P2000'
<-- Tattach Tag 0 fid 0 afid -1 uname kenji aname
@@ -59,7 +54,7 @@ Plan9というOSはネットワークを介して複数のコンピュータを
<p>
まず最初にクライアントがサーバーに対してTversionを送り、プロトコルのバージョンと、メッセージの最大サイズを交渉する。Tversionのタグは<code>65535</code>と決められている。<code>msize</code>の8192はメッセージの最大サイズ(バイト)で、<code>version</code>の9P2000がプロトコルのバージョンである。サーバーからRversionで同じ<code>msize</code>と<code>version</code>が返ってきたのでこのサイズとバージョンで以降の通信を行う。</p>
<p>
-次のTattachで、クライアントがサーバーにルートディレクトリの<code>fid</code>を要求する。<code>afid</code>以降は認証用の情報である(後述)。<code>fid</code>はコネクションにおいてファイルと紐付けられる整数で、Unixにおけるファイルディスクリプタのようなものである。ファイルの読み書きはこの<code>fid</code>を使って行われる。サーバーからの<code>Rattach</code>にはルートディレクトリの<code>qid</code>が含まれる。これはサーバー上でファイルを一意に識別するもので、Unixにおけるinodeに相当するものである。以上でサーバーに繋いでセッションを確立できた。</p>
+次のTattachで、クライアントがサーバーにルートディレクトリの<code>fid</code>を要求する。<code>afid</code>以降は認証用の情報である(後述)。<code>fid</code>はコネクションにおいてファイルと紐付けられる整数で、Unixにおけるファイルディスクリプタのようなものである。ファイルの読み書きはこの<code>fid</code>を使って行われる。サーバーからのRattachにはルートディレクトリの<code>qid</code>が含まれる。これはサーバー上でファイルを一意に識別するもので、Unixにおけるinodeに相当するものである。以上でサーバーに繋いでセッションを確立できた。</p>
<p>
次にTwalkで目的のファイル(<code>hello</code>)までファイルツリーを辿る。ここでは起点として先程得られたルートディレクトリ(<code>fid = 1</code>)を起点として、このディレクトリ内の<code>hello</code>ファイルを要求して<code>fid = 2</code>を割り当てようとしている。サーバーはルートディレクトリ内に要求されたファイルが見付かったので、そのファイルの<code>qid</code>を返す。</p>
<p>
@@ -69,7 +64,7 @@ Plan9というOSはネットワークを介して複数のコンピュータを
<p>
最後に、必要なくなった<code>fid</code>はTclunkで捨てる。</p>
-<h3>List of all Message Types</h3>
+<h2>List of all Message Types</h2>
<table>
<tr>
@@ -159,18 +154,19 @@ Plan9というOSはネットワークを介して複数のコンピュータを
9Pにはクライアントの認証が組込まれていない。もともとはあったようだが、認証のアルゴリズムに欠陥が見付かったりすればいちいちコードを修正してコンパイルしなおさなければいけないうえ、9Pプロトコル自体も変更しないといけないので、外部に切りだすことになった。認証に必要なやりとりは認証サーバーとクライアントが行い、9Pサーバーは認証が成功したかどうかの情報を認証サーバーに確認することでクライアントの確認を行う。
</p>
<p>
-9PサーバーはTattachメッセージを受けとると、認証サーバーとのコネクションを確立する。その後<code>Rattach</code>メッセージで<code>afid</code>という特殊なFidをクライアントに返す。クライアントからこの<code>afid</code>に対して読み書きする命令が届くと、9Pサーバーはこの読み書きを認証サーバーとのコネクションに横流しする。つまりクライアントはこの<code>afid</code>を通じて認証サーバーと直接やりとりができる。クライアントはユーザー名やパスワード等(パスワード認証の場合)の情報を<code>afid</code>に書き込んで認証する。このように認証をプロトコル自体から切り離すことで、認証に関するバグが見付かったとしても、認証サーバーを修正するだけでいい。また、より強力な認証システムを組み込むのも楽である。
+9PサーバーはTattachメッセージを受けとると、認証サーバーとのコネクションを確立する。その後Rattachメッセージで<code>afid</code>という特殊な<code>fid</code>をクライアントに返す。クライアントからこの<code>afid</code>に対して読み書きする命令が届くと、9Pサーバーはこの読み書きを認証サーバーとのコネクションに横流しする。つまりクライアントはこの<code>afid</code>を通じて認証サーバーと直接やりとりができる。クライアントはユーザー名やパスワード等(パスワード認証の場合)の情報を<code>afid</code>に書き込んで認証する。このように認証をプロトコル自体から切り離すことで、認証に関するバグが見付かったとしても、認証サーバーを修正するだけでいい。また、より強力な認証システムを組み込むのも楽である。
</p>
<h2>コネクションの共有</h2>
<p>
クライアントはサーバーと<code>version</code>メッセージを交すことでコネクションを確立する。コネクションの確立からの一連のやりとりをセッションという。ひとつのコネクションは複数のクライアントが共有できる。</p>
<p>
-クライアントはTauthまたはTattachメッセージによりサーバーに<code>fid</code>を要求できる。このうちTauthにより得られた<code>fid</code>は認証以外には使えない。Tattachで得られた<code>fid</code>は、Twalkメッセージによりファイルツリーを辿るための起点として利用でき、このとき辿った先のファイルを示す<code>fid</code>が生成される。これ以外の方法で<code>fid</code>が増えることはない。つまり、サーバーはひとつのコネクションのなかで、から派生した<code>fid</code>を追跡することで、クライアントを区別できる。</p>
+クライアントはTauthまたはTattachメッセージによりサーバーに<code>fid</code>を要求できる。このうちTauthにより得られた<code>fid</code>は認証以外には使えない。Tattachで得られた<code>fid</code>は、Twalkメッセージによりファイルツリーを辿るための起点として利用でき、このとき辿った先のファイルを示す<code>fid</code>が生成される。これ以外の方法で<code>fid</code>が増えることはない。つまり、サーバーはひとつのコネクションのなかで、ルートディレクトリから派生した<code>fid</code>を追跡することで、クライアントを区別できる。</p>
<h2>メッセージ詳細</h2>
<p>
-各メッセージの詳細を書く。それぞれ最初にメッセージの形式を書く。<code><i>field</i>[<i>n</i>]</code>は<code><i>field</i></code>という名前の<i>n</i>バイトのデータを表す(<i>n</i>は整数)。また、括弧の中が整数ではなくsになっている場合、そのフィールドは文字列のデータで、その前に文字列の長さを示す2バイトのデータが先行する。</p>
+それぞれ最初にメッセージの形式を書く。<code><i>field</i>[<i>n</i>]</code>は<code><i>field</i></code>という名前の<i>n</i>バイトのデータを表す(<i>n</i>は整数)。また、括弧の中が整数ではなく<code>s</code>になっている場合、そのフィールドは文字列のデータで、その前に文字列の長さを示す2バイトの整数が先行する。また、メッセージ名のフィールド(<code>Tversion</code>等)にはメッセージの種類を表す1バイトのenumが来る。
+</p>
<h3>version</h3>
<p>
プロトコルのバージョンを交渉すし、コネクションを確立する。
@@ -194,9 +190,9 @@ size[4] Tattach tag[2] fid[4] afid[4] uname[s] aname[s]
size[4] Rattach tag[2] qid[13]
</code></pre>
<p>
-<code>attach</code>メッセージはサーバーのルートディレクトリを要求し、<code>fid</code>を割り当てる。認証が必要なサーバーであれば、先に<code>auth</code>メッセージで認証を済ませておき、<code>attach</code>メッセージの<code>afid</code>に、先程使用した<code>afid</code>をセットする。サーバーはこの<cdoe>afid</code>に紐付いている認証サーバーにクライアントが認証済みであるかを確認し、認証済みであればルートディレクトリの<code>qid</code>を返す。サーバーが複数のファイルツリーを公開している場合、<code>aname</code>で指定する。</p>
+<code>attach</code>メッセージはサーバーのルートディレクトリを要求し、<code>fid</code>を割り当てる。認証が必要なサーバーであれば、先に<code>auth</code>メッセージで認証を済ませておき、<code>attach</code>メッセージの<code>afid</code>に、先程使用した<code>afid</code>をセットする。サーバーはこの<code>afid</code>に紐付いている認証サーバーにクライアントが認証済みであるかを確認し、認証済みであればルートディレクトリの<code>qid</code>を返す。サーバーが複数のファイルツリーを公開している場合、<code>aname</code>で指定する。</p>
<p>
-<code>auth</code>メッセージは認証サーバーとやりとりするための<code>fid</code>である<code>afid</code>を要求する。この<code>afid</code>を読み書きすることで認証サーバーとやりとりをし、自身を身分を証明する。認証が済んだらこの<code>afid</code>をセットした<code>attach</code>メッセージを送る。</p>
+<code>auth</code>メッセージは認証サーバーとやりとりするための<code>fid</code>である<code>afid</code>を要求する。この<code>afid</code>を読み書きすることで認証サーバーとやりとりをし、自身の身分を証明する。認証が済んだらこの<code>afid</code>をセットした<code>attach</code>メッセージを送る。</p>
<h3>error</h3>
<p>
@@ -205,7 +201,7 @@ size[4] Rattach tag[2] qid[13]
<pre><code>size[4] Rerror tag[2] ename[s]
</code></pre>
<p>
-クライアントからの要求に対して、なにかエラーがおきたときにそのエラーを返すために使われる。そのためサーバーからクライアントへの<code>Rerror</code>はあるが逆向きのTメッセージはない。</p>
+クライアントからの要求に対して、なにかエラーがおきたときにそのエラーを返すために使われる。<code>Terror</code>はない。</p>
<h3>flush</h3>
<p>
diff --git a/pub/sitemap.xml b/pub/sitemap.xml
@@ -1,10 +1,10 @@
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
+<url><loc>https://www.mtkn.jp/</loc><lastmod>2024-12-19</lastmod></url>
+<url><loc>https://www.mtkn.jp/computer/9p.html</loc><lastmod>2024-12-19</lastmod></url>
<url><loc>https://www.mtkn.jp/computer/</loc><lastmod>2024-12-18</lastmod></url>
-<url><loc>https://www.mtkn.jp/computer/9p.html</loc><lastmod>2024-12-18</lastmod></url>
<url><loc>https://www.mtkn.jp/journal/posts/20241211.html</loc><lastmod>2024-12-11</lastmod></url>
<url><loc>https://www.mtkn.jp/journal/</loc><lastmod>2024-12-11</lastmod></url>
-<url><loc>https://www.mtkn.jp/</loc><lastmod>2024-12-11</lastmod></url>
<url><loc>https://www.mtkn.jp/poetry/</loc><lastmod>2024-12-09</lastmod></url>
<url><loc>https://www.mtkn.jp/journal/posts/20241202.html</loc><lastmod>2024-12-02</lastmod></url>
<url><loc>https://www.mtkn.jp/kitchen/recipe/mapo_tofu.html</loc><lastmod>2024-10-10</lastmod></url>
