あもいもやっとく? - GPSS2開発日誌 -

06/06/29(木)

[][] trac準備したよ 22:01

新しいGPSS2サイト用に、バグトラッキングシステムTracインストールますた

http://g2.wda.jp/trac

こちらからどうぞ。

Subversionリポジトリブラウザも無事動いてます。素敵。

ついでに、XMLソケットスレで面白い動きがあるようなので、それも応援。

wikiが欲しいそうなので、同じくtracでSockletFunsページを用意しました。

http://g2.wda.jp/funs

スレの皆様、ご自由にお使いくださいませ。

06/06/10(土)

[][]α版アップロード 03:00

どうにも腰が重くていけないので、自分のケツ叩くためにも一旦α版として公開します。

http://sourceforge.jp/projects/gp-socketserver/

からどうぞ。

gpss-2.0.0a1-src.zipEclipseプロジェクトです。解凍して適当Eclipseインポートしてください。

このプロジェクト内のdistributeディレクトリを、gpss-2.0.0a1.zipとしてアップしてあります。

実行する際は、startup.batもしくはgpss2.exeをダブルクリックしてください(Windowsの場合)。

…さて、言われたそばから申し訳ないのですが、ScriptSockletは未実装です。スミマセンスミマセンスミマセン…

[][]exewrap 03:00

便利なもの見つけたので、早速使ってみました。

http://www.ne.jp/asahi/web/ryo/exewrap/

これつかって、gpss2.exeを生成してあります。

(GPSS?に使うにはちょっとだけ具合が悪かったので、改良版を使ってます。)

これで、「起動できないよぉ」ってことが減ると…いいなぁ。

06/06/04(日)

[][]Sockletの配備方法の変更 01:20

GPSS1では、Sockletの配備までGPSSサーバで面倒を見ていました。

まり、接続一発目のコマンドはGPSSサーバ自体で解釈し、その後にSockletに引き渡す、というようないろいろとややこしい処理が入っていました。

GPSS2ではその部分をばっさりカット

GPSSサーバ純粋にソケットの待ち受けのみに徹することになりました。

ではどうするのかと言いますと、GPSSサーバには必ず1つだけデフォルトのSockletを登録するようにして、接続を受け付けると有無も言わさずそのデフォルトのSockletにクライアントを預け、コマンド処理はそちらに任せてしまう、といった処理になりました。

このデフォルトのSockletを、特別にSockletDeployerと呼びます。

SockletDeployerは、必ずSockletDeployerインターフェースを実装する必要があります。

また、SockletDeployerインターフェースを実装したクラスSeasarのDICONに登録すると、自動的にGPSSサーバにDIされます。

ですので、GPSS1では接続後一発目のコマンドについてはGPSSの仕様として限定されてしまっていましたが、GPSS2ではSockletDeployer次第で如何様にも書けるようになりました。

と言うわけで、HTTPの受け答えも書けると思います。>> HTTPポーリングによる接続

また、2chスレの方で話も出てた、FACEs用のアプリケーションをがっつり移植ができちゃうSockletDeployerも作っちゃおうかな、なんて野望も抱いてたりしますw

thecoolmuseumthecoolmuseum 2006/06/04 05:51 >>GPSS1では接続後一発目のコマンドについてはGPSSの仕様として限定されてしまっていましたが、GPSS2ではSockletDeployer次第で如何様にも書けるようになりました。
キタキタという感じです。まさに汎用化に向かって前進ですねぇ。
GPSS1ではうちで書いてたセキュリティー部分とか、CROSSDOMAIN部分とかが本体に食い込んでしまいソースを汚してて心苦しかったんですよねぇ。
これからは必要な機能だけをよりエレガントに実装できそうですね。

06/06/03(土)

[][] なぜSockletの仕様が変わってしまったのか 22:43

相変わらずドキュメント、というか文章は下手なので、意味不明な表現がありましたらご遠慮なく突っ込みお願いします。

メソッド名の問題。

checkConnection / preRemoveClient がどうにも気持ち悪かったので、メソッド名を変更しました。

accept:クライアント受け入れ処理←checkConnectionから変更

denied:クライアント接続拒否処理(新設)

desert:クライアント切断処理処理←preRemoveClientから変更

あぁ、すっきり(笑)

実はSockletインターフェースには従来どおり、checkConnection / preRemoveClient の両メソッドを残してあります。

GeneralSockletの基底クラスの checkConnection / preRemoveClient にてアクセスコントロール処理を行うようにしましたので、Sockletを実装する段階では記述する必要がなくなっただけです。

なので、GeneralSockletを使用せずに0からSockletを開発する場合は、やはり checkConnection / preRemoveClient メソッドを実装する必要はあります。

また、Socklet間の連携についてはSeasarに管理してもらうことにしたので、GPSS2では特に記述する必要はなくなりました。

よって、これまた気持ちの悪かったafterDeployedLinks/allowAccessFromOtherSocklet等のメソッドは廃止となりました。

クライアント管理の問題。

S2のHotSwapに対応させるために、Sockletに接続中のクライアントを持たせるわけには行きませんでした。

なぜなら、Sockletに直接接続中のクライアント達一覧を持たせておくと、Sockletを入れ替えた際にインスタンスが初期化され、クライアントが切断されてしまうためです。

(多分、新しいS2のHotDeployでも同様だと思うのですが…)

その他の理由もありますが、なんにしてもSockletには「状態」を持たせないことにして、接続中のクライアント等、Sockletに関する「状態」は別のインスタンスで管理することにしました。

そうなりますと、コマンド処理メソッドの引数として「現在接続中のクライアントたち」を渡す必要が出てきてしまいまして、doCommandメソッドの仕様も変更になってしまいました。

thecoolmuseumthecoolmuseum 2006/06/03 23:51 徐々にG2の全貌が明らかに・・・期待です!