Conexión TCP no http en Cloudfoundry

Soy un desarrollador de móviles nooby que trata de aprovechar el servicio de cloudfoundry para ejecutar mi servidor para manejar algunos chats y movimientos de personajes. Estoy usando Noobhub para lograr esto (conexión TCP entre el servidor y el cliente usando la API de conexión TCP de Node.js y Corona SDK)

Básicamente, estoy intentando una conexión TCP no http entre Cloudfoundry (Node.js) y mi máquina (lua).

Enlace a Noobhub (Hay un repository de github con servidor e implementación del lado del cliente.

estoy haciendo

Cliente

... socket.connect("myappname.cloudfoundry.com", 45234) ... 

(45234 es del valor process.env.VCAP_APP_PORT del servidor que recuperé de la salida de la consola que obtuve a través de “vmc logs myappname” después de ejecutar la aplicación.)

Servidor

 ... server.listen(process.env.VCAP_APP_PORT) 

Cuando bash conectarme, solo se agota el tiempo.

En mi máquina local, haciendo cliente

 ... socket.connect("localhost",8989) 

Servidor

 ... server.listen(8989) 

Funciona como se espera. Es solo en cloudfoundry que no funciona.

Probé un montón de otras formas de hacer esto, como establecer la conexión del puerto del cliente a 80 y un montón de otros. Vi algunos recursos pero ninguno de ellos lo resolvió. Usualmente soplo al hacer preguntas, así que si necesitas más información, ¡pregúntame!

PD

Antes de lanzarme este enlace con una cara enojada D: <, aquí hay una pregunta que muestra un problema similar que otra persona publicó.

no se puede conectar al servidor TCP en CloudFoundry (localhost node.js funciona bien)

Desde aquí, puedo ver que este tipo estaba tratando de hacer algo similar a lo que yo estaba haciendo. ¿La respuesta seleccionada significa que DEBO usar el encabezado del host (es decir, usar el protocolo http) para conectarme? ¿Eso también significa que cloudfoundry no admitirá un socket TCP “VERDADERO” como heroku o app niebla?

En realidad, la variable de entorno process.env.VCAP_APP_PORT proporciona el puerto, al cual el enrutador Cloud Foundry L7 (nginx) redirige su tráfico HTTP según la ruta de sus aplicaciones (por ejemplo, nodejsapp.vcap.me:80 se redirige al process.env.VCAP_APP_PORT puerto process.env.VCAP_APP_PORT en la máquina virtual), por lo que definitivamente no debe usarlo para la conexión TCP. Este puerto se debe utilizar para escuchar el tráfico HTTP. Es por eso que su ejemplo funciona localmente y no funciona en Cloud Foundry.

El enfoque que funcionó para mí es escuchar el puerto proporcionado por CF con un servidor HTTP y luego adjuntarlo al servidor Websocket (websocket.io en mi ejemplo a continuación). He creado un servidor de eco de muestra que funciona tanto localmente como en CF. El contenido de mi archivo Node.js llamado example.js es

 var host = process.env.VCAP_APP_HOST || "localhost"; var port = process.env.VCAP_APP_PORT || 1245; var webServerApp = require("http").createServer(webServerHandler); var websocket = require("websocket.io"); var http = webServerApp.listen(port, host); var webSocketServer = websocket.attach(http); function webServerHandler (req, res) { res.writeHead(200); res.end("Node.js websockets."); } console.log("Web server running at " + host + ":" + port); //Web Socket part webSocketServer.on("connection", function (socket) { console.log("Connection established."); socket.send("Hi from webSocketServer on connect"); socket.on("message", function (message) { console.log("Message to echo: " + message); //Echo back socket.send(message); }); socket.on("error", function(error){ console.log("Error: " + error); }); socket.on("close", function () { console.log("Connection closed."); }); }); 

La dependencia lib websocket.io podría instalarse ejecutando el npm install websocket.io en el mismo directorio. También hay un archivo manifest.yml que describe los argumentos de despliegue de CF:

 --- applications: - name: websocket command: node example.js memory: 128M instances: 1 host: websocket domain: vcap.me path: . 

Entonces, ejecutando cf push desde esta aplicación implementada en el directorio a mi instancia local de CFv2 (configurada con la ayuda de cf_nise_installer ) Para probar este servidor websocket de eco, usé el archivo index.html simple, que se conecta al servidor y envía mensajes (todo está registrado en la consola):

      ws://     

Lo único que queda por hacer es ingresar la dirección del servidor en el cuadro de texto de la página de Index (websocket.vcap.me en mi caso), presionar el botón Conectar y tenemos una conexión de Websocket activa a través de TCP que se puede probar enviando Ping y recibiendo eco. Eso funcionó bien en Chrome, sin embargo, hubo algunos problemas con IE 10 y Firefox.

¿Qué pasa con el socket TCP “VERDADERO”? No hay información exacta: según el último párrafo aquí, no puede usar ningún puerto excepto el 80 y el 443 (HTTP y HTTPS) para comunicarse con su aplicación desde fuera de Cloud Foundry, lo que me hace pensar que TCP socket no puede ser implementado. Sin embargo, de acuerdo con esta respuesta, puedes usar cualquier otro puerto … Parece que se requiere una investigación profunda sobre esta pregunta …

“Cloud Foundry usa un enrutador L7 (ngnix) entre los clientes y las aplicaciones. El enrutador debe analizar HTTP antes de que pueda enrutar las solicitudes a las aplicaciones. Este enfoque no funciona para protocolos no HTTP como WebSockets. La gente que ejecuta node.js irá a tiene este problema, pero no hay soluciones fáciles en la architecture actual de Cloud Foundry “. – http://www.subbu.org/blog/2012/03/my-gripes-with-cloud-foundry

Decidí ir con pubnub para todas mis necesidades de mensajería.

    Intereting Posts