XSSTP/1.0

仕様策定の目的

この仕様の目的は、SSTPの完全再設計ではありません
eXtended SSTPの名の通り、今後容易に拡張可能な状態でのSSTP実装の検討を目指します。
基本的に、現SSTPのコマンド体系の変更は一部を除き行いません。

解決すべき課題

  • 改行を含む値を投げられない
  • そこそこの量のデータになると途端に効率が悪くなる

仕様メモ

複数行のデータ、量の多いデータの送信のために、Content-Lengthヘッダを定義します。
あわせて、返値にこれまで全くヘッダがなかったところを、特にCharsetヘッダ必須と規定します。

Keep-Aliveを追加します。HTTPのそれと同じで、1接続で複数のコマンド送受信ができることを意図しています。
通常Windows上ではこのような場合DirectSSTPを利用しますが、それが使えないその他のOS上での実装を考慮しています。

……ただし、どのOSにも軽めのプロセス間通信機構くらいあるでしょうから、それでDirectSSTPもどきを提案することをおすすめします。SocketSSTPの最大の難点は、9801番ポートを占有できるのは1プロセスのみという話ですし。
ということで、書いてはみたもののKeep-Aliveは保留扱いの予定です。

要するに、HTTP/1.0のマネゴトです。

送信

EXECUTE XSSTP/1.0
Charset: Shift_JIS
Command: SetProperty
Reference0: system.hoge
Keep-Alive: 1
Content-Length: 4

hoge

返値

XSSTP/1.0 200 OK
Charset: Shift_JIS
Content-Length: 8
Keep-Alive: 300

hogehoge

追記

  • Content-Length: -1のとき、「これから送るべきデータの長さはわからないので、こちらが切断するまで届いたデータを全て受信せよ」という指示となります。
    • ヘッダが無い場合は0扱いです。空行が現れるまで処理して後は受信しません。
    • 無論これで巨大なデータを送ろうとする良からぬ輩も現れるでしょうから、実装ではある程度以上溜め込みそうになったら強制中断をかけるよう注意する必要があります。
    • DirectSSTPでは、そもそもコネクションの概念がなく、毎度送るだけですので、Content-Length: -1を多用することになるでしょう。
  • Keep-AliveヘッダはDirectSSTPでは無視されます。SocketSSTPでは、サーバ側で返値受信後も接続を維持します。
    • クライアント側からはKeep-Alive: true、もしくはKeep-Alive: 1を送ります。
    • サーバ側からは次の送信まで待機する秒数が返されます。この秒数を過ぎるとタイムアウト扱いとなり、切断されます。

問題点

  • 互換性なし
  • Keep-Aliveの実装が複雑
    • DirectSSTPのような手段のないOS上での利用を考えて提案された方がいて追記しましたが、いちいちちょん切ってもどうせloop-backアドレスにしか送らないでしょうし、それだとたいしたオーバーヘッドは無いと思うんですけどね……

ツッコミコーナー



トップ   編集 凍結 差分 履歴 添付 複製 名前変更 リロード   新規 一覧 検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2006-12-09 (土) 22:51:32