#ついでなのでsrfi-98のサポートを足しました。
#やった！
#srfi で socket の提案があるとうれしいなと思いつつ難しいだろうな。BSD Socket に期待される動作・仕様の部分は、srfi の仕様書には書かなくてもよいなら多少は楽かもしれないけど。
#srfi-98はコードは2行で済むんですけどドキュメントを足すのが億劫で (あちこちクロスリファレンスを入れなくちゃならないので) さぼってました。
#socketは難しいですね。ほんとに簡単なサーバ/クライアントを実現するだけならかなり共通化して書けるけど、それではトイプログラム程度しか書けない。実用的にしようとするとソケットオプションを考慮したりソケットアドレスをちゃんと扱ったりせざるを得なくなる。
#いっそ、レイヤをひとつ上げたメッセージパッシングAPIみたいな感じにして、障害時の適切な動作だけ順当なものを決めておき、泥臭い部分は全部実装に任せる、とした方がいいかもしれない。
#>それではトイプログラム程度しか書けない。実用的にしようとするとソケットオプションを考慮したりソケットアドレスをちゃんと扱ったりせざるを得なくなる。
#同意です。
##一方で↑くらいの機能があれば簡単な http server/client が書けるので
#標準があった方が良いなあと。
#sockopt 相当は処理系に任せれば良いくらいの気持ちで。
#Ruby はBSD ソケットまんまだ。
##raw socket作る時はserviceは単に無視されるの?
#SOCK_RAW はサポートしていないです。
#クライアント側だと簡単なAPIでもそんなに問題ないかも。
#そうなんです＞クライアント
#それこそ twitter クライアント作りたいと思ったら必要な機能はたかが知れている感じ。
#サーバ側は、REUSEADDRが指定できないとか、ipv4/v6両方で待つサーバをポータブルに書けないとかいうのはかなり問題になる。
#twitterクライアント、ちゃんと動くやつにしたかったらタイムアウト問題に対応しないとならないんじゃない? それは別レイヤにすべきかなあ。
#自分の実装は REUSEADDR はデフォルトです。
#確かに＞タイムアウト
#tcpの永遠待ち問題は抽象化の破れだと思うんで、どっちかというとネットワークライブラリで対応されてるといい感じだと思うんだけど。
#ipv6 はお仕事系では要求がありそうですね。
#というより、システムがv6サポートしてる場合、何も考えずにサーバ作ったら自動的にv4/v6両方で待ってくれる、っていう方がいいと思う。
##その場合、「ソケット」というのはちょっと粒度が細かすぎる。
#なるほど。v6がどれくらい必要とされるか全然知らなくてそのあたりの感覚を持ち合わせていないです。
#お昼ご飯行ってきます〜。
#たぶん、陽に必要とされることってそんなに無いと思うんだけれど、だから簡易APIだとわざわざv6対応しようとは思わないと思うんだよね。で、そういうv4べったりのsocket srfiをベースにしたライブラリがどんどん作られて、後でv6対応したいと思った人が見たら、Schemeの高レベルネットワークライブラリはたくさんあるけど全部v4べったりで結局自分で書き直さないとだめだぁ、ってなったらあんまり嬉しくない。
#他のやつの基礎になるsrfiなら、そこだけアップグレードすれば上に乗っかったやつは全部その恩恵を受けられるってほうが嬉しい。
#v6対応ではまったことはないんだけど、低層に縛られた例として、CLの何かのライブラリでhttpのハンドリングからボディのhtmlのパージングまでやってくれるやつがあったんだけど、文字エンコーディングのハンドリングが不十分で結局使えなかったってことがあった気がする。
#なるほど。となると socket srfi を提案する人にはそのあたりのバランス感覚が必要ですね。
#簡易socket APIの問題点として、それをベースにして上に抽象化レイヤを積み上げられない、というのがある。
#ちょっと考えてたんだけど、高レベルのレイヤで必要な機能はなんだろう。
#通信端点オブジェクト(ハンドル)、通信相手の指定、ブロッキング時の対応、相手消滅時の対応、複数のチャネルを待つこと、あたり?
#そのへん、「チャネル」みたいなオブジェクトでひとつレイヤを組めないだろうか。
#ふむふむ。組めそうですね＞チャネル。いわゆるメッセージング。ところで socket もそういう目的の抽象化レイヤーだとも思います。登場の背景や環境が古いので今から見るとややこしいですが。
#うまく Scheme のポートに乗ると良さそうですね。ソケットがバイナリポートとして見えるイメージ。
Gauche > Archives > 2010/04/14