そんなわけはなくw

抗うつ剤が切れたので、5週間のマニラ生活を終えて帰国。でも来週水曜にまたマニラに戻るって、どうよ?

そんな生活なのでココイチ のカキフライカレーをやっと食べました。うん、汁はあまり出なかったけど今年のカキも合格点です。出張生活なので、今年は食べる回数が減りそうだなぁ。

そんなカキフライカレーお預け状態に我慢できなかったというわけではないのですが、定宿にしているマニラダイアモンドホテルの日本食料理屋で、2度ほどカキフライカレーを裏メニューで作らせて見ました。衣の状態、カレールーの濃さ、カキの質などココイチのそれとは違いますが、なかなかいけます。機会があれば、ご注文ください。レギュラーメニュー化を目指してますw

カキフライカレーで通じない場合は、カツカレーの豚の代わりにカキを使うように言えばいいかと思います(最初そうやって注文しました)。

以前.NET Remotingで双方向通信 をやる方法を調べてまとめておいたのですが、要約するとクライアント側にあるdelegateオブジェクトを.NET Remotingを通じてサーバに渡しておけば、サーバーがそのdelegateを呼ぶことによってクライアント側の関数が呼び出されるというもの。

しばらくこの方法で使用していたのですが、このdelegateを呼び出す時によく分からないタイミングで

This remoting proxy has no channel sink which means either the server has no registered server channels　that are listening, or this application has no suitable client channel to talk to the server.

などという非常に長いメッセージを持つ例外が発生、サーバー→クライアントの呼び出しが失敗してしまいました。

このメッセージをキーワードにして検索すると、文字数が多いため結構ピンポイントで同じ問題を扱っている海外サイトにヒット。どうやらdelegateを呼び出す時にサーバー側がクライアントのどのポートにどのプロトコルで通信すればいいのか分からなくなるらしいです。

今回はサーバーへの接続を開始する前にクライアント側で以下の処理をして、クライアントが受け付けるチャンネル(sink)を宣言しました。

int portnum = 10000;
string name = "RemoteClient";
SoapServerFormatterSinkProvider sinkProvider = new SoapServerFormatterSinkProvider();
sinkProvider.TypeFilterLevel = System.Runtime.Serialization.Formatters.TypeFilterLevel.Full;
ChannelServices.RegisterChannel(new HttpServerChannel(name, portnum, sinkProvider), false);

上記はHTTPプロトコルでSOAP形式でシリアライズ、クライアントが受け付けるポートは10000ということになりますので、TCP接続やBinaryシリアライズなどは適当に読み替えてください。英語ですが検索すれば、TCP接続やBinaryシリアライズの方が例はたくさん見つかります。

この例のようにクライアント側に書くコードですが、やっていることはサーバのそれ。サーバーがクライアントのdelegateを呼び出すという形をとってますが、その実はサーバーとクライアントが立場を入れ替えてソケット通信しているということなのでしょう。

Cook Computing の内容によると、この例外はdelegateだけでなく何らかの参照がサーバに渡され実体はクライアントだけにしかない場合に発生するとのこと。まぁ、冷静に考えてみればそうかな。

それまで問題なく動いていたプログラムが突然この例外を発生するようになり、以後ほぼ全てのサーバー→クライアント方向の通信が例外発生。どのタイミングでだめになるんですかねぇ。リース時間などと関係あるのだろうか、調べてる時間ない orz

[参考]

• RemotingException and Missing Channel Sink (Cook Computing)
• No Sink on Remoting Proxy to Client (CodeGuru Forums)

[2009/10/4 追記]構成ファイルだと以下の内容で動作しましたが、いまひとつ自信なし。MSのサイト行っても<channels>以下に具体的にどう書けばいいのか、ほとんど書いてないんですよねぇ・・・

<configuration>
  <system.runtime.remoting>
    <application name="Client">
      <channels>
        <channel ref="http" port="10000">
          <clientProviders>
            <formatter ref="soap" typeFilterLevel="Full" />
          </clientProviders>
          <serverProviders>
            <formatter ref="soap" typeFilterLevel="Full" />
            <provider ref="soap"/>
          </serverProviders>
        </channel>
      </channels>
    </application>
  </system.runtime.remoting>
</configuration>

落雷は滅多に撮影する機会に恵まれません。前回撮影したのは10年ほど前のメキシコでしょうか。日本じゃ遠くまで見渡せる&カメラ持ってる状況で、落雷に出会うことがまず無いからでしょうね。

いざその機会に恵まれても、なかなかシャッターチャンスが来ません。空が光ることは1～2分に一度あるのですが、その多くが雲の中だけで終わってしまい地上に落ちてこない、地上に落ちてもカメラがその方向を向いてなかったなど・・・以前富士山登ってたときに北の方角に落雷が見えていたのですが、遠かったのと撮影に30分以上かかる可能性もあり一緒に登っていた人を待たせるわけにもいかず断念したことも。

一度途中で枝分かれする落雷を撮影してみたいですねぇ

15年以上使っている腕時計 ですが、昨日飛行機の中でふと目をやると、針が取れてる…取れたのは赤丸で囲んだ曜日を示す小さな針。本来はその上のSUN|MON|...と円周上に書いてある部分の中心に付いていたもので、先日の写真 と見比べると分かりやすいかと思います。

まさかこんな壊れ方するとは思ってなかったのですが、普段この時計で曜日はあまり確認しませんし、日付に到っては合わせもしてない(何月かを分かっているわけじゃないので、小の月を過ぎると日付を設定しなおさないといけません)ので、まだまだ使えますｗ

先週急に決定し、今日から再びフィリピンへ出張。しかも今回の航空券は正規もしくは普通運賃といわれるもの。

私の知っている限りでは、航空券は大別して普通・PEX・格安の3段階の価格があり、後のものほど安くなります。普通と格安では倍近くの価格差があることも。これらで異なるのは座席の質やサービスではなく、後から日程が変更できるかと現地滞在日数。格安は発券された後は全く日付の変更ができないのに対して、PEXは1～3回、普通運賃は無制限。現地滞在日数も、格安は2～3週間が限度に対して普通運賃は最長1年。

旅行などの場合は現地で病気にでもならない限りは日程を変更することもないので格安で事足りますが、仕事となると特に帰りの日付が変えられないというのは結構不自由。しかし企業であっても格安の値段は魅力であり、極力格安を選択するように言われています。

ではなぜ、今回一番高価な普通運賃にしたのか。長丁場になりそう&何回帰国を延期するか分からないから…ということなのです orz いつ帰れるのよ

ちなみに昔はとりあえず格安を購入、帰国延期になったら乗らずに現地で新たに帰りの片道航空券を購入なんてことやってたのですが、いつの間にやら格安やPEXで帰国便に乗らないと高額の違約金(片道普通運賃と同額が相場)を取られるようになったらしく、この方法も使えず。