2

CloudFoundry で実行されている TCP サーバーの例に接続できません。ローカルの node.js インストールで app.js ファイルを実行すると、問題なく動作します。具体的には、vmc push を使用して CloudFoundry を実行すると、サービスが開始され、クラッシュしません。一部の IP がそれに接続し、切断し、私が知る限り、サービスは実行され続けます。

「telnet」も「nc」も使用して接続できません（localhost node.jsサーバーに向けられた場合、これらは両方とも正常に機能することに注意してください。

これは失敗します:

> nc themagicsandbox2.cloudfoundry.com 8124

これは機能します

> nc localhost 8124
hello from TCP server! (intended reply)

私のコードはここに提出され、Cloud Foundry stdout.log はその下に提出されます。

コード：

myTrace('loaded'); // myTrace prepends timestamp to text and sends to console.log

var tcpServer = require('net').createServer(function(sock) { //'connection' listener
    sock.on('connect', function() {
        myTrace('client ' + sock.remoteAddress + ':' + sock.remotePort +' connected');
        sock.write('hello from TCP server!\r\n');
        sock.pipe(sock);
      });

    sock.on('end', function() {
        myTrace('client disconnected');
      });
  });



tcpServer.listen(8124, process.env.VCAP_APP_HOST || "localhost");

tcpServer.on('listening', function() {
      myTrace('server is listening - bound!');
    });

tcpServer.on('error', function(err) {
     myTrace('server err: ' + err);
     if (err.code == 'EADDRINUSE') {
       myTrace('Address in use, retrying ...');
       setTimeout(function() {
           tcpServer.close(function (err) {
               myTrace('server.close: ' + err);
             });
           tcpServer.listen(SLIDEIN_TCP_PORT, process.env.VCAP_APP_HOST || "localhost");
         }, 1000);
     }
  });

tcpServer.on('close', 
          function() {
            myTrace('server has closed');
             });

stdout.log (CloudFoundry):

Getting file contents... OK

Fri Mar 15 2013 11:59:02 GMT+0000 (UTC) loaded
Fri Mar 15 2013 11:59:02 GMT+0000 (UTC) server is listening - bound!
Fri Mar 15 2013 11:59:03 GMT+0000 (UTC) client 172.30.50.10:31840 connected
Fri Mar 15 2013 11:59:03 GMT+0000 (UTC) client disconnected

標準出力 (localhost node.js):

Fri Mar 15 2013 12:57:39 GMT+0100 (CET) loaded
Fri Mar 15 2013 12:57:39 GMT+0100 (CET) server is listening - bound!
Fri Mar 15 2013 12:57:53 GMT+0100 (CET) client 127.0.0.1:52260 connected
Fri Mar 15 2013 12:57:59 GMT+0100 (CET) client disconnected
Fri Mar 15 2013 12:58:00 GMT+0100 (CET) client 127.0.0.1:52261 connected
Fri Mar 15 2013 12:58:01 GMT+0100 (CET) client disconnected
4

3 に答える 3

1

これは、要求がホスト ヘッダーを使用してアプリケーションにルーティングされるためです。netcat も telnet もどちらも送信しません。これらのいずれかでリクエストを行うと、おそらくルーターから 504 が返されます。

于 2013-03-15T13:42:17.857 に答える
0

問題は、TCP クライアントと cloudFoundry アプリケーションの間にプロキシまたは HTTP リダイレクタがあることだと思います。

リダイレクションはHOSTの「ヘッダー」によって制御されるというダン・ハイマンの答えは、リダイレクターがクライアントがHTTPプロトコルを使用していると想定し、「ホスト」ヘッダーレコードを持っているため、どのcloudFoundryアプリを使用しているかを判断できるという事実に基づいています。と話したい。

アプリケーションへの非 HTTP TCP 接続を取得する方法を尋ねていると思います。私もそれを理解していません。VCAP_APP_HOST 環境変数はプライベート IP アドレス (つまり、プライベート 10.0.0.0 サブネット内) を提供するため、パブリック インターネットからクラウド ホストに到達するのに役立ちませんでした。(クラウド ホストの同じネットワークによって提供されるアプリ間の通信に役立つ場合があります。)

于 2013-03-29T21:09:53.827 に答える
-1

単方向であり、このサーバーのニーズをカバーする UDP を使用して問題を回避しようとしました。データを受信するための受信専用プロトコルで間に合わせることができます。

ただし、ポートが開かれていないため、UDP は CloudFoundry.com では機能しません。

ここのコメント スレッドを参照してください: Cloud Foundry で使用するアプリに対して、HTTP および HTTPS ポートのみが開かれています。

結局のところ、HTTP を介してこのサーバーにデータを送信することに戻ったようです。HTTP ハンドシェークを取り除くことが、この TCP サーバーを最初に作成した基本的な理由でした。

于 2013-03-18T15:39:12.973 に答える