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

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/09(金)

[]*はてなの使い方

日記の消し方がわからねぇ…orz

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の全貌が明らかに・・・期待です!

06/05/30(火)

[]ちょっとしたメモ 00:11

svn+sshを使うために

Subclipsesvn+sshを使うためには、JavaHLではなくて、JavaSVNを使ったほうがよさげ。JavaHLではうまくいかんとです。

svn+sshユーザを分ける

authorized_keysに書いてある鍵の前に、

command="svnserve -t -r (レポジトリ) --tunnel-user=(ユーザ)" ssh-rsa A...

としてあげると、Linuxアカウントじゃなくてtunnel-userで指定したユーザがログに記録されます。

詳しくは http://subversion.bluegate.org/doc/ch06s03.html

同じSVNサーバで複数のユーザを使い分ける

ホスト名が同じだと同じ鍵を使おうとしちゃうようなので、hostsファイルにでも適当ホスト名を登録して、鍵毎に擬似的に違うホスト名を指定してやるとよさげ。

TortoiseSVNで、svn+ssh

Eclipseの「ウィンドウ」→「設定」→「チーム」→「CVS」→「SSH2接続メソッド」→「鍵管理」で生成したRSA鍵を使うためには、まず作った鍵をPuTTY形式の鍵に変換する必要があります。-> puttygen.exe http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html を使うと変換できます。

参考)http://www.chitta.com/nobu/text/?pid=49

次にTortiseSVN設定→ネットワークにある「SSHクライアント」を以下のように編集します。

TortoisePlink.exe -l (システムアカウント名) -i (鍵へのパス) -C

TortoisePlink.exe、及びPuTTY形式の鍵へのパスはフルパスで書いてください。

ちなみにSubclipseでは、PuTTY形式の鍵を使用する必要はありません。

TODO:TortiseSVNで複数の鍵を使い分けるには?

誰か知ってたら教えてください。