要約

  • James E. WhiteはRFC 707で、ARPANETのアプリケーション用プロトコルに重複していたコマンドと応答の処理を減らすため、共通のProcedure Call Protocolと実行環境を提案した。
  • 文書はTENEXを動かすPDP-10向けの試作を報告する一方、遠隔呼び出しはIPCメッセージを必要とし、ローカル呼び出しより高くつき、すべての通信を表現できるわけではないと述べている。

ローカルに見える構文の、その先

遠隔処理を関数呼び出しの形で書ければ、アプリケーションは読みやすくなる。しかし相手の機械が離れている事実は変わらない。1973年のFTP仕様では、ファイル名変更をRENAME FROMとRENAME TOの二つのコマンドで行う。Remote Job Entryにも独自のコマンド列と応答があり、処理中に進捗を返す場合もあった。各アプリケーションは、自分の機能だけでなく、通信の会話の進め方も抱えていた。

RFC 707『A High-Level Framework for Network-Based Resource Sharing』は、その重複を共通化する案だった。執筆者James E. Whiteは、Stanford Research Institute（SRI）のAugmentation Research Centerに所属していた。提案の狙いはメッセージをなくすことではない。アプリケーションごとの命令文法を減らし、処理を手続きと引数で記述できるようにすることだった。

呼び出しと戻り値をどう運ぶか

Procedure Call Protocol（PCP）はCALLとRETURNのメッセージを組み合わせ、トランザクション識別子で要求と結果を結び、引数や戻り値を扱う。複数の要求を同時に保留する設計も含む。各設置先の実行環境が呼び出しを整え、遠隔側と通信し、結果を呼び出し元へ渡す。ブロッキングと非ブロッキングの双方、さらにサーバー側からクライアントへの呼び戻しも構想された。

これはアプリケーションが見るインターフェースの整理であって、通信層の消去ではない。分散プログラムは非同期に進み得るし、ストリームのように手続き呼び出しへ収まりにくい通信もある。RFC 707は、そうした場合に使える下位のプロセス間通信（IPC）を残すべきだとした。

TENEX試作が示す範囲

RFCの記述によると、ARCの研究は1974年7月に始まり、12か月にわたって三度設計を改めた。チームはPDP-10上のTENEX向け実行環境を設計・文書化し、試作を実装した。文書は、そのTENEX実装が仕様を実装し、説明された能力を上回る機能を備えたと報告する。

この記述は、名前の挙がった機種とOSで動く試作があったという、提案を越えた証拠になる。ただし異なる機種間の相互運用性、導入台数、利用者数、ARPANET全体への展開は示さない。現在のRFC EditorはRFC 707をLegacy、状態UNKNOWNと分類し、IETF Datatrackerは正式なソース記録より前の文書で、現行のIETF標準化手続き上の地位を持たないと説明している。現在の分類から当時の利用規模を推定することもできない。

抽象化しても通信費は残る

RFC 707の注意書きは明確だ。ローカルの手続き呼び出しは安価だが、遠隔呼び出しはIPCメッセージを要する。プログラマーは使いどころを選ばなければならず、分散プログラムは非同期に動くことがある。すべての有用な通信が手続き呼び出しに向くわけではない。

この境界が、記録から導ける歴史的なポイントだ。RFC 707は、アプリケーション間で重複していた要求・応答の機構を共通ランタイムへ移し、TENEX上で試したことを示す。ネットワーク全体への普及や、後年のRPC方式への因果的影響は、参照した一次資料からは確認できない。面白さは、便利な抽象化とその残余コストを同じ文書が並べている点にある。

出典

  • James E. White、RFC 707『A High-Level Framework for Network-Based Resource Sharing』。
  • RFC EditorのRFC 707記録、IETF DatatrackerのRFC 707記録。
  • RFC 542：FTPのコマンドと改名手順。RFC 360：Remote Job Entryのコマンド、応答、進捗通知。
  • RFC 592はSRIによる初期の資源共有議論の背景資料である。恒路のNote 65は後世の編集視点に限られ、1970年代の意図や普及を示す史料ではない。