大津です。
0.6.17, 0.7.8より前の Node.js で HTTPヘッダを解析する際にバグがあり、第
３者にHTTPリクエストの情報が漏れてしまう脆弱性が報告されました。
http://blog.nodejs.org/2012/05/07/http-server-security-vulnerability-please-upgrade-to-0-6-17/
悪意のあるユーザが細工したヘッダをHTTPリクエストを送信すると、続けて接続
したユーザのHTTPリクエスト情報を抜くことができます。理論上タイミングに
よっては第３者のCookie
大津です。
while(true) で回すのではなく process.nextTick() で再帰的にカウンター
を回せば、おそらくシグナルウォッチャーのコールバックを受けることが
できるはずです。
こんなこと書いちゃって process.nextTick() の再帰処理を使うコードが増えて
しまっているかもしれないので、かなり早めに注意事項をお知らせしておきます。
一昨日 isaacs から process.nextTick() の動作仕様を変更する提案がなされま
した。
process.nextTick semantics
大津です。
僕のプログラムソースが悪いのか、Linuxの設定が悪いのか、既知の問題なのか、、
もし何か情報をお持ちの方がいらっしゃれば、何でも構いませんので返信頂きた
く思います。
ちょっと質問の意図が読み取れないのですが、何が「問題」なんでしょうか？
1. もしかしたらメモリリークしているかもしれないという心配が存在すること
が問題
2. heartbeat で使用されるメモリが想定している量より大きいことが問題
3. 接続が多数になるとGCが間に合わない状況になることが問題
GC 後に不要なメモリがちゃんと解放されているなら動作的には問題ないと思う
のですけど。
大津です。
ベンチマークではサーバに対し多数（0〜1000）接続 し、disconnectやconnect
を繰り返し
Nodeのメモリ使用量を監視していますが、
定期的に使用量がグッと下がる（恐らくGC）ことはありますが、長いスパンで見
ると全体として増え続けています。
※どこかのタイミングで接続数を0（ゼロ）にしてしばらく経過すると、メモリ使
用量はNode起動時の状態に戻りますが、実運用ではあり得ない状態だと思います。
この状態であれば、例えばメモリを2GB積んだサーバの場合、
２〜３日でメモリが枯渇してしまうのではないかと危惧しています。
ちょっと使用量が大きいですね。
大津です。
なので，本当にメモリリークが発生していていずれはヒープが
枯渇するのか，それともフル GC が先延ばしにされているだけ
なのかを見極める必要があるのではないかと思います．
そういえば、node で手動GCできる方法があったなぁと思いだしたので、チョッ
ト試してみました。0.1秒毎に heartbeat を出し、クライアントから受け取った
らすかさずGCする例です。
https://gist.github.com/2840165
600heartbeat毎にメモリ状況を出力した結果です。超マメGCは見事に heap使用
量がそろってますね。他方 Node
大津です。
ちょっと質問の意図が正確につかめなかったので確認させてください。
この書き換えの結果を見る限りdomainは単一にしか持っておらず、複数のdomainが
並行して稼働するような環境では使えない。
（そんな場合は child-process で process自体を分けろ的なメッセージ？）
domain は stack 管理されているので複数扱えるはずでは？と思って「複数
domain が並行して稼働するような環境」というのが、最初通常の error throw
のケース
https://gist.github.com/3046839
大津です。
実現しようとしていることはドメイン内(d)であるクラスのメンバーが実行され
た時において3つあります。
1.そのメンバーはdisposeの影響を受けないようにしたいです。
2.更にメンバーのcallback関数はドメインd内で実行したいです。
3.また必要に応じてドメインd内にエラーをメンバーから投げ入れたいです
上記要件を私なりにまとめると、
「あるオブジェクトメソッドで実行されるスコープ内のドメインを特定のドメイ
ンに固定したい」
ということであってますか？
いま、1,2の実現のために手元で以下のようなソースを書いています
大津です。
チト対応が遅くなりましたが、 issueを出したところ今朝ベンが修正してくれま
した。
https://github.com/bnoordhuis/node-iconv/issues/62
手元で iconv@2.0.4 ではエラーにならないのを確認しましたので、もう npm
update していただいて大丈夫です。
原因ですが、結果 Visual Studio の問題（仕様？ 使い方？）に起因したもので
した。
大津です。
以下のサイトによると、
uv_async_send()を使えば別スレッドからいつでもメッセージを送信できるので
すね。
Inter-thread communication
http://nikhilm.github.io/uvbook/threads.html#inter-thread-communication
えー、 worker の中から uv_async_send() してるんですかぁ。
これ async ハンドラが thread safe じゃないような気がしますが、大丈夫なん
かなぁ？
私だったら condition variable
大津です。
ご意見募集です。
まだ worker 内の sleep(1) に依存した実装になってますよね。
(sleep(1) を外すと uv_async_send() が正常に動作しなくなる）
これ、 sleep(1) を入れないと、イベントループが io poll で call back を処
理する前に各スレッドが async fd を上書きしちゃうからだと思います。（ちゃ
んと調べてないですが）
先に述べたよう uv_check() を使った実装だとこんな感じになります。
(これは worker 内に sleep(1) は必要ないです）
大津です。
ありがとうございます、この方法で目的が達成できました。
良かったです。
ただ、既存アプリに手を入れないで、Webブラウザへのログ出力機能が実現でき
たら、
結構色々な用途で使えて便利だなと思いました。
この手の問題は環境に依存する部分が強そうなので答えが一つに定まらないと思
いますが、
何かよい方法があれば教えて頂けないでしょうか。
うー、「既存の任意のアプリの（どんなのかわからない）出力を、このアプリに
一切手を加えず別のアプリの入力に渡す何か良い方法はないか？」という一般的
な質問になりますよね。ホント環境依存です。
大津です。
これ、 sleep(1) を入れないと、イベントループが io poll で call back を処
理する前に各スレッドが async fd を上書きしちゃうからだと思います。（ちゃ
んと調べてないですが）
uv_async_tはスレッド毎に必要なようです。
１つのuv_async_tを重複して使っていたのが原因でした。
スレッド毎に用意したら正しく動きました。
だから最初に書いた通り、
えー、 worker の中から uv_async_send() してるんですかぁ。
これ async ハンドラが thread safe
大津です。
(2013/04/18 13:33), yuichiro wada wrote:
いただいたコードをちょっといじって動かしてみました。そこそこのサイズだと
すぐにキャッシュが終わってしまい、とても大きいファイルでテストすると、メ
モリの制限？でいろいろとギクシャクするので、手動ではなかなかうまく想定シ
ナリオをテストできませんが、動いているようには見えます。
if (cache[f]) {
cache[f].getContent(function(err, buf) {
response.writeHead(200, headers);
大津です。
v0.8 の場合はきっちり確実に止まります。
IncomingMessage 自体がバッファリングして、pause()
中は 'data' イベントを emit() しないからです
(fs.ReadStream も同様)。
うぅ、 koichik さんのパッチ。
https://github.com/joyent/node/commit/e6b6075024e9f1330575b10d7e6552e1ea6dad56
おみそれいたしました。 (_o_) さすがです。
--
---
このメールは Google グループのグループ「Node.js
大津です。
Node の spawn()
の問題というより、単なるJavaScriptの文字列指定の問題なんですが、「\文字列」はエスケープシーケンスとして認識されるので、パス中の
\をJavaScriptの文字列で利用するなら \\ と書かないといけません。
なので、
var command = 'C:\\cmd\\std.bat';
と書いたらたぶんうまく動くでしょう。
一度 command 変数を console.log() などで確認されたらよいかと思います。
(2013/05/19 18:52), 竹内佑介 wrote:
お世話になっています、竹内です。
大津です。
リスナ登録を共通化しても、結局は io と ios の2つのインスタンスを扱うので、ブロードキャストやルームの共有は難しいんじゃないでしょうか。
クライアントIPの情報は失われますが、stunnel や stub 等使って TLSの終端し、socket.io の方にリレーして http
で共通して受けるというやり方が楽じゃな
いかと思います。
(2013/05/19 19:04), e2u@gmail.com wrote:
こんにちは、福田と申します。
現在、socket.ioでブラウザとリアルタイム通信を行なっているのですが、ブラウザ側の
。
(2013/11/19 14:13), Shigeki Ohtsu wrote:
大津です。
最初簡単にチェックできるのかなと考えていたのですが、思いのほか複雑になりました。
POSTでリクエストボディで送られてくるサイズをサーバでチェックするには次の2通りあります。
1) クライアントが Content-Length を送ってからボディを送信する時。
これは一番簡単で Content-Length のサイズをチェックしてはじけばいいだけ。
2
17 matches
Mail list logo
