Node.js TCP Socket Server в облаке [Heroku/AppFog]

Ответ 1

Я достаточно уверен, что не отвечает на поставленный вопрос: "Возможно ли запустить ориентированное на ws-приложение w630.js TCP Socket". Все компании PaaS (включая Nodejitsu) поддерживают HTTP [S] - только обратные прокси для входящих подключений.

Как правило, с Node.js + любым PaaS с подключением, ориентированным на сокет, вы хотите использовать WebSockets, но:

• Heroku не поддерживает WebSockets и будет удерживать ваше соединение только на 55 секунд (см. https://devcenter.heroku.com/articles/http-routing#timeouts)

• AppFog не поддерживает WebSockets, но я не уверен, как они обрабатывают длительные HTTP-соединения.

• Nodejitsu поддерживает WebSockets и будет держать ваши соединения открытыми до закрытия или reset. Наши обратные прокси-серверы Node.js делают это очень дешевым для нас.

В будущем у нас есть планы по поддержке балансировки нагрузки TCP на передней панели с пользовательскими портами. Оставайтесь с нами!

Ответ 2

AppFog и Heroku предоставляют вашему приложению один произвольный порт для прослушивания, на который порт сопоставляется с портом 80. Вы не можете выбрать свой порт. Если вам нужно поддерживать соединение открытым в течение длительного времени, см. Мое редактирование ниже. Если вашему клиенту не нужно поддерживать и открывать соединение, вам следует подумать о создании успокоительного API, который испускает json для вашего клиентского приложения. Порт 80 более чем подходит для этого, и Node.js и Express создают превосходную комбо для создания API-интерфейсов на paas.

AppFog

https://docs.appfog.com/languages/node#node-walkthrough

var port = process.env.VCAP_APP_PORT || 5000;

Heroku

https://devcenter.heroku.com/articles/nodejs

var port = process.env.PORT || 5000;

EDIT. Как уже упоминалось, indexzero, AppFog и Heroku поддерживают только http [s] и закрывают длинные поддерживаемые соединения. AppFog будет поддерживать соединение открытым, пока есть активность. Это можно обойти, используя Socket.io или сторонние решения, такие как Pusher

// Socket.io server
var io = require('socket.io').listen(port);
...
io.configure(function () { 
  io.set("transports", ["xhr-polling"]); 
  io.set("polling duration", 12); 
});

Ответ 3

tl; dr - с текущим состоянием мира, он просто невозможен; вы должны приобрести виртуальную машину со своим общедоступным IP-адресом.

Все поставщики PaaS, которые я нашел, имеют HTTP-маршрутизатор перед всеми своими приложениями. Это позволяет им размещать сотни тысяч приложений под одним IP-адресом, значительно улучшая масштабируемость и, следовательно, - как они предлагают бесплатный хостинг приложений. Таким образом, в случае HTTP заголовок Hostname используется для уникальной идентификации приложений.

Однако в случае TCP для идентификации приложения необходимо использовать IP-адрес. Поэтому для того, чтобы это сработало, провайдеры PaaS были вынуждены выделить вас из своего диапазона IPv4. Это не будет масштабироваться по двум основным причинам: адресное пространство IPv4 было полностью исчерпано, а медленные темпы "устаревших" сетей затрудняли физическое перемещение виртуальных машин. ( "устаревшие" сети относятся к сетям стандарта/не SDN.)

Решение этих двух проблем - IPv6 и SDN, хотя я предвижу вездесущий SDN, прибывающий до того, как IPv6 делает - который затем может быть использован для решения различных проблем IPv4. Amazon уже использует SDN в своих датацентрах, хотя еще предстоит пройти долгий путь. Тем временем просто купите экземпляр контейнера виртуальной машины /linux с открытым IP-адресом и запустите там свои TCP-серверы.