commit e19deed169c371c8f6b36124caeb0f05a87c8786
parent 70f9fad22ef3cdd4d10691cc169296b42466a4dd
Author: Matsuda Kenji <info@mtkn.jp>
Date: Mon, 4 Nov 2024 21:10:41 +0900
update
Diffstat:
3 files changed, 141 insertions(+), 16 deletions(-)
diff --git a/man/draft/9p.html b/man/draft/9p.html
@@ -249,14 +249,12 @@ Unixのinodeに相当するものである。\
また、より強力な認証システムを組み込むのも楽である。
</p>
-<h2>コネクションとセッション</h2>
+<h2>コネクションの共有</h2>
<p>
クライアントはサーバーと<code>version</code>メッセージを交すことで\
コネクションを確立する。\
-コネクションが確立できたら、<code>attach</code>メッセージでセッションを\
-確立する。\
-ひとつのコネクションには複数のセッションが作れる。\
-このセッションはプロトコルに暗黙のうちに組込まれている。\
+コネクションの確立からの一連のやりとりをセッションという。\
+ひとつのコネクションは複数のクライアントが共有できる。\
</p>
<p>
クライアントは<code>Tauth</code>または<code>Tattach</code>メッセージにより\
@@ -265,11 +263,9 @@ Unixのinodeに相当するものである。\
<code>Tattach</code>で得られた<code>fid</code>は、\
<code>Twalk</code>メッセージによりファイルツリーを辿るための起点として利用でき、\
このとき辿った先のファイルを示す<code>fid</code>が生成される。\
-こえ以外の方法で<code>fid</code>が増えることはない。\
+これ以外の方法で<code>fid</code>が増えることはない。\
つまり、サーバーはひとつのコネクションのなかで、<code>Tattach</code>から\
-派生した<code>fid</code>を追跡することで、セッションが区別できる。\
-セッションを確立したあと、セッションIDなどがなくても区別できるので、\
-暗黙のうちのセッションである。\
+派生した<code>fid</code>を追跡することで、クライアントを区別できる。\
</p>
<h2>メッセージ詳細</h2>
@@ -301,7 +297,7 @@ size[4] Rversion tag[2] msize[4] version[s]
<h3>attach、auth</h3>
<p>
-セッションを確立する。
+コネクションを確立する。
</p>
<pre><code>\
size[4] Tauth tag[2] afid[4] uname[s] aname[s]
@@ -310,5 +306,90 @@ size[4] Rauth tag[2] aqid[13]
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>
+<p>
+<code>auth</code>メッセージは認証サーバーとやりとりするための\
+<code>fid</code>である<code>afid</code>を要求する。\
+この<code>afid</code>を読み書きすることで\
+認証サーバーとやりとりをし、自身を身分を証明する。\
+認証が済んだらこの<code>afid</code>をセットした\
+<code>attach</code>メッセージを送る。\
+</p>
+
+<h3>error</h3>
+<p>
+エラーを返す。
+</p>
+<pre><code>\
+size[4] Rerror tag[2] ename[s]
+</code></pre>
+<p>
+クライアントからの要求に対して、なにかエラーがおきたときに\
+そのエラーを返すために使われる。\
+そのためサーバーからクライアントへの<code>Rerror</code>はあるが\
+逆向きのTメッセージはない。\
+</p>
+
+<h3>flush</h3>
+<p>
+リクエストをキャンセルする。
+</p>
+<pre><code>\
+size[4] Tflush tag[2] oldtag[2]
+size[4] Rflush tag[2]
+</code></pre>
+<p>
+実行中の要求をキャンセルする。\
+キャンセルしたいリクエストの<code>tag</code>を<code>oldtag</code>にセットする。
+</p>
+
+<h3>walk</h3>
+<p>
+ファイルツリーを移動する。
+</p>
+<pre><code>\
+size[4] Twalk tag[2] fid[4] newfid[4] nwname[2] nwname*(wname[s])
+size[4] Rwalk tag[2] nwqid[2] nwqid*(qid[13])
+</code></pre>
+<p>
+<code>fid</code>を起点に移動する。\
+移動先のファイルを<code>newfid</code>にセットする。\
+移動するディレクトリの数を<code>nwname</code>に、\
+移動するディレクトリの名前を移動する順に<code>wname</code>に\
+それぞれセットする。\
+例えばカレントディレクトリから<code>./dir1/dir2/</code>に\
+移動する場合、<code>nwname</code>は<code>2</code>、<code>wname</code>は\
+<code>{"dir1", "dir2"}</code>となる。\
+<code>wname</code>の最後の要素はディレクトリでなくファイルでもいい。\
+</p>
+<p>
+<code>wname</code>の最初の要素への移動が失敗した場合は\
+<code>Rerror</code>が返される。\
+それ以外の場合は<code>Rwalk</code>が返され、\
+<code>qid</code>は移動が成功した順番にそのファイルの<code>qid</code>\
+がセットされる。\
+<code>nwname</code>と<code>nwqid</code>が一致した場合は\
+最後まで移動できたことになる。\
+</p>
+
+<h3>open, create</h3>
+<h3>create</h3>
+<h3>read</h3>
+<h3>write</h3>
+<h3>clunk</h3>
+<h3>remove</h3>
+<h3>stat, wstat</h3>
<h2>Goによる実装</h2>
diff --git a/pub/draft/9p.html b/pub/draft/9p.html
@@ -171,11 +171,11 @@ Plan9というOSはネットワークを介して複数のコンピュータを
9Pサーバーは<code>Tattach</code>メッセージを受けとると、認証サーバーとのコネクションを確立する。その後<code>Rattach</code>メッセージで<code>afid</code>という特殊なFidをクライアントに返す。クライアントからこの<code>afid</code>に対して読み書きする命令が届くと、9Pサーバーはこの読み書きを認証サーバーとのコネクションに横流しする。つまりクライアントはこの<code>afid</code>を通じて認証サーバーと直接やりとりができる。クライアントはユーザー名やパスワード等(パスワード認証の場合)の情報を<code>afid</code>に書き込んで認証する。このように認証をプロトコル自体から切り離すことで、認証に関するバグが見付かったとしても、認証サーバーを修正するだけでいい。また、より強力な認証システムを組み込むのも楽である。
</p>
-<h2>コネクションとセッション</h2>
+<h2>コネクションの共有</h2>
<p>
-クライアントはサーバーと<code>version</code>メッセージを交すことでコネクションを確立する。コネクションが確立できたら、<code>attach</code>メッセージでセッションを確立する。ひとつのコネクションには複数のセッションが作れる。このセッションはプロトコルに暗黙のうちに組込まれている。</p>
+クライアントはサーバーと<code>version</code>メッセージを交すことでコネクションを確立する。コネクションの確立からの一連のやりとりをセッションという。ひとつのコネクションは複数のクライアントが共有できる。</p>
<p>
-クライアントは<code>Tauth</code>または<code>Tattach</code>メッセージによりサーバーに<code>fid</code>を要求できる。このうち<code>Tauth</code>により得られた<code>fid</code>は認証以外には使えない。<code>Tattach</code>で得られた<code>fid</code>は、<code>Twalk</code>メッセージによりファイルツリーを辿るための起点として利用でき、このとき辿った先のファイルを示す<code>fid</code>が生成される。こえ以外の方法で<code>fid</code>が増えることはない。つまり、サーバーはひとつのコネクションのなかで、<code>Tattach</code>から派生した<code>fid</code>を追跡することで、セッションが区別できる。セッションを確立したあと、セッションIDなどがなくても区別できるので、暗黙のうちのセッションである。</p>
+クライアントは<code>Tauth</code>または<code>Tattach</code>メッセージによりサーバーに<code>fid</code>を要求できる。このうち<code>Tauth</code>により得られた<code>fid</code>は認証以外には使えない。<code>Tattach</code>で得られた<code>fid</code>は、<code>Twalk</code>メッセージによりファイルツリーを辿るための起点として利用でき、このとき辿った先のファイルを示す<code>fid</code>が生成される。これ以外の方法で<code>fid</code>が増えることはない。つまり、サーバーはひとつのコネクションのなかで、<code>Tattach</code>から派生した<code>fid</code>を追跡することで、クライアントを区別できる。</p>
<h2>メッセージ詳細</h2>
<p>
@@ -194,7 +194,7 @@ size[4] Rversion tag[2] msize[4] version[s]
<h3>attach、auth</h3>
<p>
-セッションを確立する。
+コネクションを確立する。
</p>
<pre><code>size[4] Tauth tag[2] afid[4] uname[s] aname[s]
size[4] Rauth tag[2] aqid[13]
@@ -202,6 +202,50 @@ size[4] Rauth tag[2] aqid[13]
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>
+<p>
+<code>auth</code>メッセージは認証サーバーとやりとりするための<code>fid</code>である<code>afid</code>を要求する。この<code>afid</code>を読み書きすることで認証サーバーとやりとりをし、自身を身分を証明する。認証が済んだらこの<code>afid</code>をセットした<code>attach</code>メッセージを送る。</p>
+
+<h3>error</h3>
+<p>
+エラーを返す。
+</p>
+<pre><code>size[4] Rerror tag[2] ename[s]
+</code></pre>
+<p>
+クライアントからの要求に対して、なにかエラーがおきたときにそのエラーを返すために使われる。そのためサーバーからクライアントへの<code>Rerror</code>はあるが逆向きのTメッセージはない。</p>
+
+<h3>flush</h3>
+<p>
+リクエストをキャンセルする。
+</p>
+<pre><code>size[4] Tflush tag[2] oldtag[2]
+size[4] Rflush tag[2]
+</code></pre>
+<p>
+実行中の要求をキャンセルする。キャンセルしたいリクエストの<code>tag</code>を<code>oldtag</code>にセットする。
+</p>
+
+<h3>walk</h3>
+<p>
+ファイルツリーを移動する。
+</p>
+<pre><code>size[4] Twalk tag[2] fid[4] newfid[4] nwname[2] nwname*(wname[s])
+size[4] Rwalk tag[2] nwqid[2] nwqid*(qid[13])
+</code></pre>
+<p>
+<code>fid</code>を起点に移動する。移動先のファイルを<code>newfid</code>にセットする。移動するディレクトリの数を<code>nwname</code>に、移動するディレクトリの名前を移動する順に<code>wname</code>にそれぞれセットする。例えばカレントディレクトリから<code>./dir1/dir2/</code>に移動する場合、<code>nwname</code>は<code>2</code>、<code>wname</code>は<code>{"dir1", "dir2"}</code>となる。<code>wname</code>の最後の要素はディレクトリでなくファイルでもいい。</p>
+<p>
+<code>wname</code>の最初の要素への移動が失敗した場合は<code>Rerror</code>が返される。それ以外の場合は<code>Rwalk</code>が返され、<code>qid</code>は移動が成功した順番にそのファイルの<code>qid</code>がセットされる。<code>nwname</code>と<code>nwqid</code>が一致した場合は最後まで移動できたことになる。</p>
+
+<h3>open, create</h3>
+<h3>create</h3>
+<h3>read</h3>
+<h3>write</h3>
+<h3>clunk</h3>
+<h3>remove</h3>
+<h3>stat, wstat</h3>
<h2>Goによる実装</h2>
</article>
diff --git a/pub/rss.xml b/pub/rss.xml
@@ -5,8 +5,8 @@
<description>ウェブページの更新履歴</description>
<language>ja-jp</language>
<link>https://www.mtkn.jp</link>
-<lastBuildDate>Sat, 2 Nov 2024 21:29:33 +0900</lastBuildDate>
-<pubDate>Sat, 2 Nov 2024 21:29:33 +0900</pubDate>
+<lastBuildDate>Mon, 4 Nov 2024 21:10:24 +0900</lastBuildDate>
+<pubDate>Mon, 4 Nov 2024 21:10:24 +0900</pubDate>
<docs>https://www.rssboard.org/rss-specification</docs>
<item>
<title>麻婆豆腐</title>
