commit 70f9fad22ef3cdd4d10691cc169296b42466a4dd
parent 9c7d3e98a08e12b465084af9601bdfa0854a5f25
Author: Matsuda Kenji <info@mtkn.jp>
Date: Sat, 2 Nov 2024 21:38:06 +0900
update
Diffstat:
3 files changed, 139 insertions(+), 6 deletions(-)
diff --git a/man/draft/9p.html b/man/draft/9p.html
@@ -125,8 +125,6 @@ Unixにおけるinodeに相当するものである。\
最後に、必要なくなった<code>fid</code>は<code>Tclunk</code>で捨てる。\
</p>
-<h3>認証</h3>
-
<h3>List of all Message Types</h3>
<table>
@@ -216,5 +214,101 @@ Unixにおけるinodeに相当するものである。\
ルートディレクトリの<code>fid</code>が設定され、\
<code>Twalk</code>により追加され、<code>Tclunk</code>により削除される。\
</p>
+<p>
+<code>qid</code>はサーバーがファイルを一意に識別するためのもので、\
+Unixのinodeに相当するものである。\
+ただしinodeはファイルが削除されると再利用される可能性があるのに対し、\
+<code>qid</code>は再利用できない。\
+<code>qid</code>はこのファイルがディレクトリかどうか等を示す<code>type</code>、\
+ファイルが変更されたときにインクリメントされる<code>vers</code>、\
+そしてファイルを一意に表す<code>path</code>の3つの情報で構成される。\
+</p>
+<h2>認証</h2>
+<p>
+9Pにはクライアントの認証が組込まれていない。\
+もともとはあったようだが、認証のアルゴリズムに欠陥が見付かったりすれば\
+いちいちコードを修正してコンパイルしなおさなければいけないうえ、\
+9Pプロトコル自体も変更しないといけないので、外部に切りだすことになった。\
+認証に必要なやりとりは認証サーバーとクライアントが行い、\
+9Pサーバーは認証が成功したかどうかの情報を認証サーバーに確認することで\
+クライアントの確認を行う。
+</p>
+<p>
+9Pサーバーは<code>Tattach</code>メッセージを受けとると、\
+認証サーバーとのコネクションを確立する。\
+その後<code>Rattach</code>メッセージで<code>afid</code>という\
+特殊なFidをクライアントに返す。\
+クライアントからこの<code>afid</code>に対して読み書きする命令が届くと、\
+9Pサーバーはこの読み書きを認証サーバーとのコネクションに横流しする。\
+つまりクライアントはこの<code>afid</code>を通じて認証サーバーと\
+直接やりとりができる。\
+クライアントはユーザー名やパスワード等(パスワード認証の場合)の情報を\
+<code>afid</code>に書き込んで認証する。\
+このように認証をプロトコル自体から切り離すことで、\
+認証に関するバグが見付かったとしても、認証サーバーを修正するだけでいい。\
+また、より強力な認証システムを組み込むのも楽である。
+</p>
+
+<h2>コネクションとセッション</h2>
+<p>
+クライアントはサーバーと<code>version</code>メッセージを交すことで\
+コネクションを確立する。\
+コネクションが確立できたら、<code>attach</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>
+
+<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>
+<h3>version</h3>
+<p>
+プロトコルのバージョンを交渉すし、コネクションを確立する。
+</p>
+<pre><code>\
+size[4] Tversion tag[2] msize[4] version[s]
+size[4] Rversion tag[2] msize[4] version[s]
+</code></pre>
+<p>
+クライアントは最初にサーバーにこのメッセージを送ってバージョンと\
+メッセージの最大サイズ(<code>msize</code>)を交渉する。\
+サーバーはクライアントから送られたバージョンとメッセージサイズに\
+対応していれば、同じバージョンとサイズを送り返し、交渉成立である。\
+</p>
+<p>
+サーバーとクライアントはこのメッセージを以ってコネクションを確立する。\
+</p>
+
+<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]
+
+size[4] Tattach tag[2] fid[4] afid[4] uname[s] aname[s]
+size[4] Rattach tag[2] qid[13]
+</code></pre>
<h2>Goによる実装</h2>
diff --git a/pub/draft/9p.html b/pub/draft/9p.html
@@ -78,8 +78,6 @@ Plan9というOSはネットワークを介して複数のコンピュータを
<p>
最後に、必要なくなった<code>fid</code>は<code>Tclunk</code>で捨てる。</p>
-<h3>認証</h3>
-
<h3>List of all Message Types</h3>
<table>
@@ -163,6 +161,47 @@ Plan9というOSはネットワークを介して複数のコンピュータを
<h2><code>fid</code>と<code>qid</code></h2>
<p>
<code>fid</code>はコネクションにおいてファイルを指定するために使われる整数で、Unixのファイルディスクリプタのようなものである。使用する整数はクライアントが指定できる。サーバーに接続する際に<code>Tattach</code>により、サーバーのルートディレクトリの<code>fid</code>が設定され、<code>Twalk</code>により追加され、<code>Tclunk</code>により削除される。</p>
+<p>
+<code>qid</code>はサーバーがファイルを一意に識別するためのもので、Unixのinodeに相当するものである。ただしinodeはファイルが削除されると再利用される可能性があるのに対し、<code>qid</code>は再利用できない。<code>qid</code>はこのファイルがディレクトリかどうか等を示す<code>type</code>、ファイルが変更されたときにインクリメントされる<code>vers</code>、そしてファイルを一意に表す<code>path</code>の3つの情報で構成される。</p>
+<h2>認証</h2>
+<p>
+9Pにはクライアントの認証が組込まれていない。もともとはあったようだが、認証のアルゴリズムに欠陥が見付かったりすればいちいちコードを修正してコンパイルしなおさなければいけないうえ、9Pプロトコル自体も変更しないといけないので、外部に切りだすことになった。認証に必要なやりとりは認証サーバーとクライアントが行い、9Pサーバーは認証が成功したかどうかの情報を認証サーバーに確認することでクライアントの確認を行う。
+</p>
+<p>
+9Pサーバーは<code>Tattach</code>メッセージを受けとると、認証サーバーとのコネクションを確立する。その後<code>Rattach</code>メッセージで<code>afid</code>という特殊なFidをクライアントに返す。クライアントからこの<code>afid</code>に対して読み書きする命令が届くと、9Pサーバーはこの読み書きを認証サーバーとのコネクションに横流しする。つまりクライアントはこの<code>afid</code>を通じて認証サーバーと直接やりとりができる。クライアントはユーザー名やパスワード等(パスワード認証の場合)の情報を<code>afid</code>に書き込んで認証する。このように認証をプロトコル自体から切り離すことで、認証に関するバグが見付かったとしても、認証サーバーを修正するだけでいい。また、より強力な認証システムを組み込むのも楽である。
+</p>
+
+<h2>コネクションとセッション</h2>
+<p>
+クライアントはサーバーと<code>version</code>メッセージを交すことでコネクションを確立する。コネクションが確立できたら、<code>attach</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>
+
+<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>
+<h3>version</h3>
+<p>
+プロトコルのバージョンを交渉すし、コネクションを確立する。
+</p>
+<pre><code>size[4] Tversion tag[2] msize[4] version[s]
+size[4] Rversion tag[2] msize[4] version[s]
+</code></pre>
+<p>
+クライアントは最初にサーバーにこのメッセージを送ってバージョンとメッセージの最大サイズ(<code>msize</code>)を交渉する。サーバーはクライアントから送られたバージョンとメッセージサイズに対応していれば、同じバージョンとサイズを送り返し、交渉成立である。</p>
+<p>
+サーバーとクライアントはこのメッセージを以ってコネクションを確立する。</p>
+
+<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]
+
+size[4] Tattach tag[2] fid[4] afid[4] uname[s] aname[s]
+size[4] Rattach tag[2] qid[13]
+</code></pre>
<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>Mon, 28 Oct 2024 20:51:20 +0900</lastBuildDate>
-<pubDate>Mon, 28 Oct 2024 20:51:20 +0900</pubDate>
+<lastBuildDate>Sat, 2 Nov 2024 21:29:33 +0900</lastBuildDate>
+<pubDate>Sat, 2 Nov 2024 21:29:33 +0900</pubDate>
<docs>https://www.rssboard.org/rss-specification</docs>
<item>
<title>麻婆豆腐</title>
