cannot connect to TCP server on CloudFoundry (localhost node.js works fine)

Question

I have trouble connecting to my TCP server example running on CloudFoundry. When running my app.js file on a local node.js installation, it works just fine. Specifically, when I run the CloudFoundry by using vmc push, the service starts and does not crash. Some IP connects to it, disconnects and as far as I can tell, the service keeps running.

I just cannot connect to it using using neither "telnet" nor "nc" (note both of these work fine when directed towards the localhost node.js server.

This fails:

> nc themagicsandbox2.cloudfoundry.com 8124

This works

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

My code is submitted here and the Cloud Foundry stdout.log is submitted below it.

Code:

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

stdout (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

Answer 1

That's because requests are routed to your application using the host header, neither of which netcat or telnet send. When making the request with either of those you will probably get a 504 back from the router.

Answer 2

I think the problem is that there is a proxy or HTTP redirector between your TCP client and the cloudFoundry application.

Dan Highman's answer, that the redirection is controlled by the HOST 'header' is predicated on the fact that the redirector assumes that your client is using the HTTP protocol and has a 'host' header record to allow it to figure out which cloudFoundry app you want to talk to.

I think you are asking how to get a non-HTTP TCP connection to the application. I haven't figured that out either. The VCAP_APP_HOST environment var gives a private IP address (ie in the private 10.0.0.0 subnet) so that wasn't useful for getting from the public internet to the cloud host. (It may be useful for communication between apps served by the same network of cloud hosts.)

Answer 3

I tried to get around the problem by using UDP which is unidirectional and that covers the need of this server, it could make do with a receive only protocol for receiving data.

However, UDP is never going to work on CloudFoundry.com, because the ports aren't opened.

See the comment thread here: Only the HTTP and HTTPS ports are open for an app to use on Cloud Foundry

So it seems that I am back to sending data to this server over HTTP after all, getting rid of the HTTP handshaking was the fundamental reason for writing this TCP server in the first place.