正しいかどうか分からないが、埋め込みTwitterの取り込み処理と、そこからデータをDOM操作する処理を初回BackgroundWorkerでやってたのだが、BackgroundWorkerだとそのオブジェクトを生成するのに時間が掛かるらしい。
＃確かなことは分からないが、デフォルトドキュメントのカウンタログを見ると、/ と /index.htmlとの間に最大で5秒以上のタイムラグが発生しているらしい。
そこで、BackgroundWorkerをやめて、ThreadPoolを使うようにした。
すると、タイムラグは1秒以内に収まるようになった(今のところ)。
プール数とリクエスト数にも依存するかも知れないけれど、まずまずの結果かな？
これで問題が出なければ、今後、ThreadPoolを使える場所ではThreadPoolを使うことにしよう。
とりあえず、方法だけ書いておくか。
IIS用のマネージモジュールで、HTMLコンテンツに対し、カウンタと一緒に書き換えフィルタ処理を入れてある。
＃フィルタを使ったマネージモジュールの創り方は、ウィジェットのサイトカウンタって文字列をクリックな。
ただ、書き換え時にいちいちrssを取りに行くと、twitterサイトが重いときとか、回線混雑のときに応答待ちが大きくなるので、定期的にメモリ上に取り込むのを別途タイマーかけてやってる。
本当にちゃんと保持できてるかは未確認だけど、一応、シングルトンクラス内でタイマー使ってるから、保持できているはずだ。
保持したrss(XML)をごにょごにょ弄って書き換えるのは、いちいちやってる・・・のは無駄だな。
＃本当なら、保持するのは書き換えに必要な加工状態のものでいいはずだよなぁ・・・ま、いいか。
OverSsl Clientのコンセプトは良いはずだ。
暗号化で安全な通信経路を保障しちゃうのは結構ありがたいはずだ。
だが、問題はいくつかある。
＃STARTTLSに対応できないのはコンセプト上、仕方ないのだが。
一番の問題は、アプリケーションの設定を変更しなければならないことだ。
この変更に対応できない場合はとても残念なことだが利用できない。
例えばWWWブラウザなどはその最たるものだ。
そして、それは、サーバーを固定指定することに起因する。
OverSsl Serverの場合は、この仕様で問題ないのだが、Clientでは問題となるわけだ。
他にも問題はあるのだけれど、この問題が解消できると、クライアントアプリケーションの設定を不要にできる可能性が出てくる。
つまり、あまりネットワークを知らない一般ユーザでも導入が簡単になる可能性がある。
http://internet.watch.impress.co.jp/docs/column/jirei/20100714_380352.html
↑この事例とそのあとの話の繋がりは少しおかしい。
無線LANの暗号化は、アクセスポイント－無線機器の間で行われるもので、通信経路全体を暗号化しているわけではない。
だから、WEPだろうがWPA/WPA2だろうが、アクセスポイントまで到達できてしまった通信は、それより先では無防備になる。
WEP解読云々は別の話である。
APで受け取ったパケットを解析すれば、無線LANの暗号化なんて、関係ないのだから。
＃だからといって、無線LAN暗号化が不要だとか、知らないAPを使っていいというわけではないので、注意。
記事の事例に限れば最も重要な解は、記事の最後の方にあるメールのSSL暗号化だ。
通信中の情報保護をするのなら、通信経路全体を暗号化する必要がある。
通信経路全体を暗号化するのならば、やはり、クライアントからサーバーまでEnd-to-Endの暗号化が保障されたほうがいい。
SSL暗号化はその一つの解で一般的だと思う。
古いクライアントアプリケーションだと、SSL暗号化通信に対応できてないものもあるので、そういう場合は、OverSsl *を使えばいいのにって話になる。
＃iOSには対応しておりませんが。
ただ、メールの場合、暗号化されたところで、所詮メールサーバーまで。
そこから先の転送(目的のアドレスのメールボックスを保有しているサーバーへの通信)が暗号化されていないと意味は薄れるわけだが。
なんか、できそうだったので、やってみた。
元ソースは過去のC/C++コード。
非同期パケットダンプがちょっと固まりやすいけれど、一応できた。
＃固まるってのは、Rawパケ採取にBackgroundWorker使ってんだけど、激しいProgressChangedによって、Form描画が詰まっちゃってるっぽい。←応急処置入れたので固まりにくくなったと思う。
あと、停止時に例外出るのは仕様。
一応、実行ファイルだけ置いておく。
OverSsl使った場合、ちゃんと暗号化されていることが、視覚的に分かるぞ。
さすがに、XP以降じゃないとダメかも。
要.NET Framework 3.5だし。
IPv6でも動くかも知れないけど、未確認。
＃IPv6ヘッダ解析はIPアドレス部分だけ入れてあるつもりだけど。
(追記)実行には管理者権限が必要です。
とりあえず、フルマネージコードでRawパケ採取できることが分かったことは収穫。
ま、PRですし、既出ですが。
まずは、OverSsl Clientをインストールして、↓こんなふうに設定を追加しますよ。
手順書は過去記事に載せてあるけど、やはりCA局を組んで、サーバー証明書を取得するのは手間であろうということで、サーバー証明書のサンプルでござる。
オレオレでござる。
OverSsl Serverで使える。
当然、IISでも使えるけどな。
FQDNは、*.sample.localになってるので、mail.sample.localとか、ftp.sample.localとか、適当な名前でどうぞ。
ルートCA証明書ととペアなので、適切にインストールすれば、そこそこ使える。
ルートCA証明書はローカルコンピュータの信頼されたルート証明機関へインポート。
サーバー証明書はローカルコンピュータの個人へインポート(パスワードはSample)。
ルートCA証明書は利用するすべてのサーバーおよびクライアントへインポート。
サーバー証明書は利用するサーバーへインポート。
＃分からなければコメントを。
公的証明機関だと、あらかじめOSに組み込まれていることが多いため、サーバー証明書の設定だけで済むのが利点。
こと暗号化通信に関して言えば、その程度の差しかない。
＃認証となると、また別の側面がある。
といっても、サポートの方だけど。
OverSsl Server / Client のサポートページを用意してみたんだけど、本当は、使用感なんかを知りたかったりする。
あと、SI(お安くしますよ)可能性について、知りたいのだけど・・・
＃証明書って買うと高いけど、小規模なら買わなくても何とかなるんですよ、ホント。
推奨する使用方法は、サーバーマシンとクライアントマシンにそれぞれインストールしてEnd-to-Endの通信暗号化なんだけど、そうじゃなくても、たとえば、サーバーマシンがLinux系だったりする場合には、リバースプロキシっぽくOverSsl Serverを間に挟んで暗号化したりもできる。
＃この挟む方法ってのはクライアントマシンでも同様なんだけどさ。
仮に既にSSL暗号化されていたとしても、そこにTCP通信があるのなら、SSL暗号化することができるので、ぜひ使ってみて欲しいんだけど・・・最近は殆どがHTTPSで済んじゃうんだよなぁ・・・
＃余談だが、認証だけHTTPSで、認証後がHTTPってのは改ざんに対しての対策になってないと思う。
Vectorに登録したのが公開されたらしい。
16:45現在、ステータスは公開済ながら、URL不明なためアクセスできないのだけど・・・
IPv6にも対応(とはいえ、OS側でサポートしてもらう必要あるけど)だから、いろいろお得。
22:30 URL通知あり。
OverSsl Server ベータ版
OverSsl Client ベータ版
とりあえず、注意すべきは使用期限と動作時間。
ベータ版だから、それぞれ制限をかけてある。
7月末までには正式版にしたいという、予定も含めて。
忘れないようにメモ。
IPv6で正しくアドレス指定しても、Connectでエラーになっていた。
「System.Net.Sockets.SocketException: 要求したプロトコルと互換性がないアドレスを使用しました。」だそうな。
IPv4指定にするとConnectを通過するので、IPv6に起因するものだと、思い至る(までに数時間)。
調べると、コンストラクタの中に、IPv6を使うか、IPv4を使うか決めるものがある。
フンガー!!
引数設定したら、例外発生しなくなり、通信できるようになった。
ムッキー!!
どのアドレスファミリで接続するかをConnectで判断しちゃいけないってことを忘れちゃいけない。
当然といえば当然なんだけど、MouseEventArgs.Buttonの値って、マウスの左右入れ替えすると、ちゃんと入れ替わってくれるのね。
入れ替わってくれなかったらどうしようって思ってたんだけど、これなら安心。
旧ブログに置いてある、WPF本から抜き出して迷路データを自動生成にしたやつをXBAP化してみたんだけど・・・・
なんか、フォーカスをうまく受け取れていない。
そのせいか、キー操作もうまくない。
酔っ払いを操作しているようで、快適とは言えない。
.NET 3.5 と 4.0で試したけど、どちらも同じ。
継承すれば、親クラスのprotectedメンバにもアクセスし放題とばかり思っていた。
この十年余り。
俺もまだまだだな。
こんなC++コードを書くと、「A& GetA(A& org)中のorg.A::GetA()呼び出しって、protectedだからアクセスできないよ～」というコンパイルエラーが出る。
A& GetA(B& org)の方は大丈夫。
なんとなーく、Aのprotectedメンバにサクサクアクセス出来ちゃいそうに思っていたので、自己修正、覚え直し。
C#でも試したけど、同様。
昨日のあれ、なんとか動いた。
いろいろあったけど、利用する証明書は秘密鍵付きじゃないとマズイってことは重要なのでメモ。
公開鍵暗号なんだから、復号化する際に必要なので、当然なんだけど・・・
昨日の画面を見ればわかる人はわかるけど、今回のサーバー版ってのには、Hosts書き換えを不要にする仕掛けを入れてあるので、とても便利。
つまり、受け取った証明書のホスト名が検証されるので、ホスト名が一致している必要があるのだけど、これを接続先アドレスと別に用意できることで、解決しちゃうという、当たり前っちゃー当たり前なことなんだけど、忘れがち。
＃クライアント版にも反映したい。
これで、バックエンドサーバーと同じ証明書を利用して、SSL-SSLの簡易プロキシ(ポートフォワード)としてポートを公開することもできる。
既出クライアントのサーバー版
やっと、ポートListenできた。
＃多分、証明書も読み込めているとは思うのだが、netstatでポートListenの確認まで。
本当に使えるかは、これから確認。
Managerで設定保存するとサービスが自動的に設定再読み込みしてくれるのはクライアント版と同様。
超手間要らず設計。
あとは、オレオレエンタープライズ証明書取得方法文書化ってやつをやっておかなきゃな・・・
＃Windows Only。
System.Net.IPAddressのコンストラクタに渡す文字列をチェックしたかったのだが、IPv4表記ならば楽にバイト列化できるけど、IPv6の場合短縮表記やら、インタフェースIDやら、IPv4埋め込みやらで、やたらと手間がかかる・・・と思っていた。
%や:や.で分割して、0埋めが必要ならどれだけか調べて置換・・・とか、いろいろやったんだけど、結局のところ、
System.Net.IPAddress.Parse
System.Net.IPAddress.TryParse
この2メソッドが異様に強力ということに。
かなり適当な表記でも、正しければIPAddressに変換してくれる。
コンストラクタ要らずで、超便利。
ただし、インタフェースID部分は数値である必要があるらしい。
VS2008(SP1)が落ちる。
「ツールボックス」で「アイテムの選択」をすると100%落ちる。
VS2010との同居に問題があるのか、よくわからない。
しかも、サクッと落ちて、例のデバッグしますか？も表示されないので、気付かないほど。
ツールボックス使わなくても何とかなるからいいんだけど、ついやっちゃった場合、未保存コードがパァになるので、注意せねば・・・
Windowsフォームアプリで入力文字を制限するのに、MaskedTextBoxを使うのはいいのだけれど、これ、マスクできる文字種が少なすぎるという欠点がある。
たとえば、16進数で可変長の文字列入力をさせたいなんて、単純なことなのにもう無理。
なんともし難い。
仕方なく、TextBox派生で、文字制限をかけるコンポーネントを実装。
でも、WndProcをオーバーライドしなきゃならんとか、コピペのことまで考えなきゃならんとか、まわりくどいことこの上ない感じ。
もっとスマートな方法があるような気がするのだが・・・
OnTextChangedはあっても、OnTextChangingは無いんだよなぁ。
この件。
性能まで考えると、やはり、アンマネージC/C++にしたほうがいいのかも知れない・・・
20100524_OverSslClientSetup.zip
TCP通信をSSL暗号化するものである。
マニュアルはまだない。
アルファ版でござる。
マネージャとサービスから成り立っている。
Yahoo!のメール設定をプリセットしてある。
Vector登録するまでには及んでいない(後述のIPv6とかに対応したい)ので、ここに置いておく。
.NET Framework 2.0～3.5xに対応している・・・はず(VS2010でビルドしたので、ちょっと不安)。
Windows 7の64bitでも、動く(32bitターゲットだから、WOW64上ってことになる)のを確認済み。
そうそう、サービスは起動後3分経つと自動停止することに加え、使用期限は2010年6月いっぱいに設定してあるので、もしも気に入って金払ってでも使いたいとかいう奇特な人いらっしゃればコメントを。
C#で勝手にDisposeしてくれる方のusing。
例外出てもDispose呼んでくれるので便利だけど、気になって確認したのでメモ。
まぁ、当たり前っちゃー当たり前だけど、後者は重要な気がする。
どんな場合でもDispose呼んでくれると思って、コンストラクタ等で例外出しまくると、意図しないことになる可能性があるってことだ。
20100521_X509Certificates_Test1.zip (実行ファイルの圧縮)
とりあえず、昨日のコードをごにょごにょして、ここまで解析できることがわかった。
でも、証明書スナップインで表示されるような「目的」を一部を除いた大部分で取得することができていない。
どうやって取ってきてるんだろうか・・・
証明書ストアにアクセスする必要があるので、コードメモ。
表示用に文字列にしたけど、ひとまずアクセスできることを確認。
使えそう。
サービスに限ったことではないが、msiインストーラプロジェクトで、Permanentプロパティの設定を間違えた。
これは、「アンインストール時に削除するかどうか」というプロパティではなく、「アンインストール時に残すかどうか」を決めるプロパティ。
＃VS2010では説明が逆なので、迷う。正しくは、残す場合はTrueで、通常はFalse(残さず削除)。
これ、間違えたままインストールすると、インストール用レジストリに、そのキーとなるファイルのインストールカウント履歴らしきものを残すらしく、その後、Permanentプロパティを正しく設定したものをインストール＆アンインストールしても、ファイルが残りまくるという現象が発生する。
これを解消するには、レジストリからキーとなっているファイル名(または単純にファイル名)に関連する部分を全部削除するしか方法はない。
要注意。
ポンコツながらも動くものができた。
今回のものは、Windowsサービス＆GUIなネットワーク系アプリケーション。
まだ、ソケット状態の把握がうまくできていないため、公開するレベルではないけれど、なかなか良い。
こいつをいくらかちゃんとしたレベルに仕上げたら、また、Vectorに登録するとしよう。
VS2010だけなのか、未確認。
ユーザーコントロールを追加して、public EventHandlerを追加した。
しかし、コンパイルして、フォームに張り付けても、プロパティウィンドウにイベントとして表示されない。
[Browsable(true)]と、BrowsableAttributeを設定してもやはり表示されない。
なぜだ？
タスクバーの時計領域って、結構でかい。
もし、これを小さくできたら、スッキリするのになぁ・・・
・・・という理由はさておき、題材としては面白いので、通知領域(タスクトレイ)に超簡易アナログ時計をアイコン表示するアプリケーションを創っちゃうぞ。
覚書きも兼ねて、図解。
C#でござる。
画面キャプチャに全部含まれているので、コードは割愛。
一般に公開されているソフトウェア使えば済む話だけど、自分で実装できたほうがいいものは結構ある。
できれば、クラスライブラリも使わず、完全フルスクラッチのほうが望ましいのだけど、長いものには巻かれてもいい。
POP3の危険性を認識している人は少ないのか、ほとんどがデフォルトでPOP3で、APOPですらない設定だったりする。
ユーザ名とパスワードを平文で送るのは、個人情報ダダ漏れが嫌な現代人にあるまじき放置状態と言っても良いのではないだろうかと。
デフォSSL＆可能ならAPOPにしたらいかがなものか。
あぁ、いかがなものか。
＃サーバ側が対応してないんだから、仕方ない。
で、無料のメールサーバでPOP3 over SSL対応にhotmailが該当するということを知り、ちょいと試してみることに。
＃「ちょい」で済む話じゃなかったりもする。
このサイトはIIS7.5でホストしているので、XBAPのホストもできる。
XBAPってのは、簡単に言うと、WPFなWindowsアプリをブラウザで使っちゃおうってもの。
手っ取り早くつくってみた。
http://lab.fne.jp/hello.net4.0/xbap/
HTMLでブリンクすればいいような気も。
VS2010でつくったので、.NET Frameworkは4.0を必要とする、たぶん。
XBAPなかなかいいんだけど、あまり浸透してないんだよね。
クロスプラットフォームなSilverlightの方が浸透してるみたい。
わざわざ、RDPで接続して、SQL Server Management Studioを起動して、テーブル参照して、編集して、とやるのが面倒なのと、そのまま外部からやろうとすると非常にリスキーなので、そういうページを1つつくっちゃいました。
つくっちゃったんですが、URLは晒さない。
晒しても問題ないように認証付けたんですが、晒さない。
自動化で対応できれば一番楽だろうということで、とりあえず、創った。
これまでの傾向として、リセット後24時間以内に無応答化するのは稀なので、1日に1回午前中にリセットするように、サービスを構成。
内部処理としては、1時間タイマーで指定の時間になったらリセットリクエストを飛ばす、それだけ。
＃つまり、○○時台でリセットすることになる。
サービスだったり、マネージコードだったりしてちゃんと動くかちょっぴり不安だけど、動かなくても、悪影響は無いはず。
リセットできるかどうかは、明日、確認。
これで運用できるなら外部からアクセスできるところに内部の制御を晒すような危険を冒す必要もない。
今度はPLANEXな。
これも問い合わせしたけど、再現性がイマイチ良くわからないので、だましだまし使っているんだけど、ときどき、SSIDが見つからなくなる。
クライアントの問題ではなく、クライアントに無関係に、接続中、切断中関係なく起こる。
コメントを暗号化して送りたいときに使うと良いと思う程度だけど、一応、SSL(HTTPS)に切り替えるためのリンクを上部に作成。
これもIISでモジュールフィルタ使って書き換えている。
サイト内リンクをhttpsに書き換える処理も入れてある。
＃トラックバックURLも書き換えちゃってるけど・・・
オレオレ証明書(ワイルドカード)なので、証明書エラーとか出まくるけど、暗号化は可能。
エラーを無くすには、ルート証明書をインストールすればいいんだけどね。
＃ルート証明書、公開してもいいと思うんだけど、躊躇中。
それこそ、気になったらコメント下さい。
＃サポートサイトでもSSL効くんだけど、オレオレだからリンク自粛。
証明書の有効期限もあるので、そのうちオレオレ認証局設置からオレオレワイルドカードSSL証明書取得やIISへのインストールまでの自己流手順書を作成しようかと思っている(予定)。
このサイトのカウンタは、IIS用マネージモジュールを使用している。
IHttpModuleを実装し、text/htmlで200レスポンスの場合だけカウンタログに入れて、クローラーかどうかを判断しつつ、カウンタログを書きだしているのは既出のとおり。
でも、どう考えてもクローラーっぽいアクセスログがあるんだけど、排除する判断が難しい。
判断が難しいのは、情報不足の気がしている。
そこで、リクエストメソッドとその他ヘッダも一緒に書きだせるように、データベーステーブルを拡張。
併せてモジュールも変更。
表示も少し変えて、過去24時間内のアクセスも併記できるようにした。
しばらくまた様子を見ることにする。
プロセス情報を操作する時例外出る場合があるようなので抑制。
ダウンロード
＃そうそう、しきい値10000ってのは結構妥当っぽい(http://technet.microsoft.com/ja-jp/windows/ee787049.aspx)のでそのまま。
＃＃曰く、「特定の時点で 1 万個を超えるハンドルを開いているプロセスは設計がよくないか、ハンドル リークが発生しているかのいずれかである～」だそうな。
当然、まだ回答は無い。
「いましばらく」という言葉は使用者や受け手、場面により、その示すであろう期間が異なる曖昧な言葉であるため、回答で使用すべきじゃないよな。
「○日までに再度ご連絡致します」って書けば、その日までは待とうと思うじゃん。
だめだよ、あの会社。
激しく表示制御をすると落ちるのは、タスクバー表示制御で何らかの問題が発生するからのようだということで、少し修正。
で、ドライバ側にも問題があるのか知らんけど、SEG CLIPの終了に失敗する場合がある。
そのときは、処理を中断する。
＃本当にどうにかしろっつうの＞IO。
で、そうなっちまった時にはデバイスを抜いて再挿入すれば、復活するっぽい。
手作業ウザし。
合法ダウンロードはこちらから。
書き忘れてたけど動作確認はXPのみ。
要.NET Framework 3.5。
記事へのIOデータからのアクセスを確認！
その後の、リファラ無しの石川県(*.infoweb.ne.jp)からのアクセスも、無関係ではないだろうと思いつつ。
既出の対策ツール、ウィンドウをそのまま出してるのもどうかと思ったので、タスクトレイに入れてみた。
単なる監視だけでタスクバーを圧迫するのもどうかと思ったし。
タスクトレイのアイコンをクリックするとウィンドウ表示・非表示されるはず。
＃初期値の設定が難しいので、最初のクリックがノーカウントになるようですが。
＃あと、あまり激しくクリックすると、落ちるようなので、注意。
終了はウィンドウを[Ｘ]で終了するか、タスクトレイアイコンを右クリックして「終了」。
最小化で隠す処理は未実装。
そんなことより、しきい値を変更できるようにしたほうがいいかもね。
＃予約録画時抑制もできればいいんだけど。
ハンドルリークを仕様とか言っちゃうダメなサポートのある会社の続き。
＃もう、伏せない。
サポートがダメだから、個人的に何とかしないとならん。
「ハンドルリークは仕様だから適宜再起動してください」では、何のサポートにもなっていないことを、IOデータは自覚すべき。
＃ま、自覚できてりゃもう少しマシな回答するんだろうけどな。
と、言ってもはじまらん。
とりあえず、再起動しないわけにはいかない。
しかし、いちいち、ハンドルカウントを確認して、再起動するのは面倒この上ない。
何が起きてるか分からんけど、どうやら、IISワーカープロセスが無応答になるらしい。
ワーカープロセス数を増やせば、ある程度抑制できるが、・・・
やはり、: Stream, IHttpModuleってのがマズイのかも。
と、思って、分離したんだけど、やはりダメ。
いや、発覚したからといってすぐに改修するわけではないが。
「/」へアクセスすると、何らかの既定ドキュメントを返すのはWWWサーバなら大抵持っている機能だけれど、IIS7.5ではどうやらモジュールがこの役割をしている・・・らしい。
＃そんな名前のモジュールが見えるよね。
で、これ、リダイレクトをさせるのではなく、また、ハンドラのように、自分で何か取ってくるわけでもなく、モジュール内でリクエストを繰り返しているっぽいんですよ。
詳しく調査したわけじゃないから、違うかも知れないけど。
ってか、もう少し早く気付けよってことで。
モジュールで受け取れるリクエスト情報にはクライアントのIPアドレスとそのホスト名があるんだけど、これ通常どちらも同じ情報が含まれている、というか、名前解決のコスト削減ってことなんだけどね。
だから、IPアドレスからホスト名を引っ張ってくる処理を入れてたわけ。
これが遅かった原因。
ログ書きをスレッド化したんだけど、そのスレッドに渡す変数(クラス)オブジェクトを構築する際にDNS引いてたから遅かった。
ログ書きスレッド内でDNS参照を行うよう変更したら、嘘のように軽くなった。
マジで、嘘みたいに軽い。
実際、カウント数集計と、レコード書き込みはどっちが先に行われているかは分からないけれど、あまり気にすることはない。
これなら、twitterの内容埋め込みもできそうな感じ・・・
＃twitter内容を定期的にローカルへ蓄えておく必要がありそうですが。
レスポンスのContent-Typeとステータスから条件判断してから、DBへのLog書きをThreadPoolに委託、フィルタチェイン構成となるよう、モジュールイベントを構成したんだけど、やはり遅い。
＃少しは改善したような気がしなくもないけれど。
さらにDB処理を削っても遅いため、恐らくDB処理は無関係だと思われる。
ならば、残りのフィルタStream自体が問題と思われる。
思われ・・・る・・・
このブログにカウンタを付けてみようかと思っていた。
普通はカウンタって、たとえば、imgタグで動的に画像を返すとか、JavaScript使ったりすると思うんだけど、それは、再リクエストを期待しないと無効なわけだし、レスポンスを返す時点でカウンタ値は決まっているわけで、いろいろと無駄があると常々思っていた。
たとえ、レスポンス一発であっても、CGI使うとか、サーバサイドインクルードとか、静的コンテンツには不向きだったりする。
前記事のとおり、IISならフィルタでレスポンス書き換えできるので、これでやってみようと思ったわけ。
.NET Frameworkでは、IHttpModuleを実装すると、IISを通過するリクエストやレスポンスを操作できるモジュールを作成できます。
たとえば、リクエストに合わせてレスポンス内容を変化させるなんてことも・・・
そう、いつも通り簡単にできるだろうと思っていました。
HttpResponse.OutputStreamの中にはレスポンスコンテンツが蓄えられるはずです。
これを読み取って、書き換えてしまえばよい、そう思っていました・・・
クッキーレスセッションを使ってみた。
WEBサーバのセッション内に一時的に記憶するメモ。
クッキーレスで、モバイル対応にした(つもり)なので、ブラウザを跨いで、各種ケータイでも使えるはず。
たとえば、
なんてことができたりする(には少し機能が足りてないかも)。
一応QRコードを出してはいる(が、内容の有効性については未確認)。
＃PNG固定(Powered by Google API)なので、PNG非対応機の場合は見えないかも。
暗号化や認証は無いので、URLバレしたらヤバい。
けれど、セッション潰す機能を付けたので、ケータイで画面メモとかしたら消しちゃえば安心。
最後のアクセスから60分、または、サーバメンテナンス等で消えます。
Azureは限りなく透明に近いブルーって感じの色らしいです。
クラウド(雲)を浮かべる空の色ってことかも。
Vector様のご厚意でAzureの無料セミナー(ハンズオン)をうけるため、はるばる静岡から日帰り(はるばるじゃねぇ)。
当初、Windows Azureって、機能特化したOSを販売するのかと思ってた。
使った分だけお支払いの仕組みを持つサービスってことらしい。
じゃ、他のウェブアプリホスティングサービスとどこが違うのか、という点については、まだよくわからないけれど、いろんな部分で、Hyper-Vっぽい仮想化技術が使われているから、ほぼノンストップだったりとか、柔軟なスケーラビリティとかの恩恵を受けることができるらしい。
あと、アプリホスティングの場合、標準のままだと、手元で作ったアプリを動かすことができなかったりする場合があるのだけれど、Azureの場合は、VisualStudioでAzure専用にアプリ開発ができるわけで、開発から実稼働までの一貫性が確保できる点は大きいような気がした。
高速化は後回し。
一応、Sleep(0)とかSystem.Windows.Forms.Application.DoEvents()とか入れてるんですけど。
マウスポインタを取得しようと思ったんです。
System.Windows.Forms.Cursor.Currentを使えばいいってことらしいんですが、これ、バックラウンドで取得すると砂時計になっちゃうし、じゃぁUIスレッドだったらいいかというと、自分の領域外では正しく取得できないという罠。
でも、何とか、VGAダミーアダプタを利用した仮想セカンダリ画面で、各種操作が可能なことを確認。
＃細かい文字を読み取るのは厳しいものがありますが・・・
2048×1536,32bitでも、XGA画面上でなんとか操作できます。
あとは、セカンダリ画面上で全て操作できるように、タスクバーもどきでも用意すれば・・・と思ったりするんだけど、もっと高速軽量化しないと無理か。
ローカルでRDPとかを使う方法って無いかしら・・・
単純な仮想スクリーンでいいじゃんってのは無し。
P.S. *.rdpで画面圧縮する呪文で満足しちゃったので、これ終了。ソース欲しい？
Formでつくって、とても遅い気がしたので、WPFにしたいと思ったところからはじまる。
いろんなところを検索して、キャプチャしたビットマップデータを表示するところまではできた。
しかし、リアルタイムで更新するにはタイマーか・・・ツールボックスに無い。
Thread.Timerを使うと、Imageへビットマップを設定するところで、違うスレッドが所有してるから変更できないとかの例外が発生する。
で、探して、見つけた↓。
WPF のスレッド: Dispatcher を使用して応答性の高いアプリケーションを構築する
そうそう、BackgroundWorker使えるんだよ。
できましたのでアップしておきましょう。
相変わらずWindows7でリサイズやXPモードの問題はありますが。
入力方向のみですが、テキストのDrag&Dropに対応ですよ。
とりあえず、できたっぽい。
favicon.icoのマネージハンドラ。
できたっぽいんだけどね。
時間(JST)を埋め込むようにしてみたんだ。
アクセスする都度変わるとおもろいと思ってたんだけど・・・
Expires指定してもfavicon.icoはキャッシュ更新されないのですよ。
なんででござろうか。
キャッシュから削除してアクセスすれば取得してくれるので、キャッシュチェックしていないわけじゃなさそうなんですが。
IE8だけかな？
ま、動くハンドラができたことと、favicon.icoが無くてログに404を記録されることが無くなったことは良いかな。
☆ボタン(右から3つ目)を付けてみました。
ポチッとサイズ変更できます。
FormBorderStyleをNone設定しておかないと、フォームサイズ最小値が正しく反映されにくい模様、というのは覚書。
で、肝心のWindows 7での動作では、やはりリサイズが有効に働かないので、☆ボタン(右から3つ目)を押すようにとのこと。
因みに、XPモードのRemoteAppだと、全画面サイズの取得ができないらしく・・・
Postボタンがキレ気味なので修正を。
レイアウト系パネルを重ねてるんだけど、どこかで自動リサイズが無効になってるとデザインモードのサイズが適用される部分が出てくるらしい・・・よくわからんけど。
既出のアプバーをアップしてみる。
動作には、.NET Framework 2.0が必要。
64bitOS未確認。
正常にPOSTできると、IDとパスワードを保存する。
＃保存するけど、暗号化はしない。
正式なAPIを使用しているかは不明。
サポートサイトでのサポートはなし。
何かあればコメントで。
C++でフォームアプリつくってたら、デザイナの挙動がおかしくなって、しまいにはデザイナエラー。
仕方ないので、C#。
でも、結果としてC#の方が楽だった。
なにやら超胡散臭い方法を多々取り入れつつできたのだけれど、なぜ例外が発生していたのか、さっぱりわからない。
try catchでも捉えきれないってのは、tryブロック外か、catchブロック内で例外になっているのかも知れないんだけど、それでも超想定外で、さっぱり。
でも、とりあえず、動くようになったから、一応信じておくとするか。
今のところ、高機能なものはいらない。
投稿さえできれば、面倒は極端に減る。
ならばというわけで、シンプルなものをつくってみた。
このサイトも実はDDNSを利用している。
MyDNSというDDNSを利用させてもらっているのだが、他のDDNSサイト同様、定期的にアドレス通知を送る必要がある。
＃というか、それでDNS情報を更新できるからDynamicDNSなわけだが。
