2013-03-15 54 views
2

我無法連接到我在CloudFoundry上運行的TCP服務器示例。當在本地node.js安裝上運行我的app.js文件時,它工作得很好。特別是,當我使用vmc push運行CloudFoundry時,服務啓動並不會崩潰。有些IP連接到它,斷開連接,並且據我所知,服務繼續運行。無法連接到CloudFoundry上的TCP服務器(localhost node.js工作正常)

我只是不能使用既不是「遠程登錄」,也不是「NC」(注意對本地主機的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 

標準輸出(本地主機的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 

回答

1

這是因爲請求路由使用您的應用程序,以主機頭,兩者都不是netcat或telnet發送的。當用這兩種方式提出請求時,你可能會從路由器回到504。

+0

是的,這是正確的,我只得到504(連接超時),謝謝。我將編寫一個使用主機頭的測試程序。 – 2013-03-15 14:37:01

+0

如果你能接受答案,那就太好了:-) – 2013-03-15 15:24:04

+0

嗨丹,我沒有忘記你。我沒有按「接受」,因爲我還沒有設法根據您的建議實施可行的解決方案。我現在就做好了。謝謝! – 2013-03-15 15:40:31

-1

我試圖通過使用單向UDP的UDP來解決這個問題,它涵蓋了對這個服務器的需求,它可以處理接收數據的只接收協議。

但是,UDP永遠不會在CloudFoundry.com上工作,因爲端口未打開。

查看評論跟帖這裏: Only the HTTP and HTTPS ports are open for an app to use on Cloud Foundry

如此看來,我回畢竟通過HTTP發送數據到這臺服務器,擺脫HTTP的握手是最根本的原因在寫這個TCP服務器第一個地方。

+1

UDP是雙向的,只是不以會話或流爲導向。但它不會出於TCP流不會的原因。 – Ribo 2013-03-29 21:13:19

0

我認爲問題在於您的TCP客戶端和cloudFoundry應用程序之間存在代理或HTTP重定向器。

Dan Highman的答案是,重定向由HOST'頭部'控制,這是因爲重定向器假定客戶端使用HTTP協議並具有'主機'頭部記錄以允許它找出你想與哪個cloudFoundry應用交談。

我想你是問如何獲得一個非HTTP TCP連接到應用程序。我還沒有想出來。 VCAP_APP_HOST環境變量提供了一個私有IP地址(即在私有10.0.0.0子網中),因此對於從公共Internet訪問雲主機沒有用處。 (這對於由同一個雲主機網絡提供的應用程序之間的通信可能很有用。)

相關問題