We have developed a webserivce built in node that susbcribes to TCP sockets to get realtime input.
Having got excited about switching from dedicated severs to PaaS I seem to have hit a brick wall in that non-http ports are not yet supported on those I've looked at.
This is a shame because quite a large class of apps are ruled out while this restriction remains.
I hear that websockets will be supported real soon now. This is goodness but not enough for the above requirement.
Have I missed anything or will I need to be super-patient on this?
On Tue, Nov 6, 2012 at 2:19 PM, Paul Tanner <p...@virtual-techno.com> wrote:
> Hi,
> We have developed a webserivce built in node that susbcribes to TCP
> sockets to get realtime input.
> Having got excited about switching from dedicated severs to PaaS I seem to
> have hit a brick wall in that non-http ports are not yet supported on those
> I've looked at.
> This is a shame because quite a large class of apps are ruled out while
> this restriction remains.
> I hear that websockets will be supported real soon now. This is goodness
> but not enough for the above requirement.
> Have I missed anything or will I need to be super-patient on this?
Having worked on load balancers I can say load balancing multiple apps on raw TCP is less than trivial. Basically you end up having to make users declare their socket needs before hand, and you assign a host:port that will map to their app inside the internals of the PaaS. If someone has good ideas on how to make this not painful for users, let me know.
On Tuesday, November 6, 2012 2:50:32 AM UTC-6, paul_tanner wrote:
> Hi,
> We have developed a webserivce built in node that susbcribes to TCP > sockets to get realtime input.
> Having got excited about switching from dedicated severs to PaaS I > seem to have hit a brick wall in that non-http ports are not yet > supported on those I've looked at.
> This is a shame because quite a large class of apps are ruled out > while this restriction remains.
> I hear that websockets will be supported real soon now. This is > goodness but not enough for the above requirement.
> Have I missed anything or will I need to be super-patient on this?
You can listen on a TCP port to process arbitrary (non-HTTP) traffic using WIndows Azure Cloud Services. There are two varieties: Web Role and Worker Role. You need Worker Role. You can set up several instances and have Windows Azure load balance traffic between them. Check out the tutorial at https://www.windowsazure.com/en-us/develop/nodejs/tutorials/getting-s....
On Tuesday, November 6, 2012 12:50:32 AM UTC-8, paul_tanner wrote:
> Hi,
> We have developed a webserivce built in node that susbcribes to TCP > sockets to get realtime input.
> Having got excited about switching from dedicated severs to PaaS I > seem to have hit a brick wall in that non-http ports are not yet > supported on those I've looked at.
> This is a shame because quite a large class of apps are ruled out > while this restriction remains.
> I hear that websockets will be supported real soon now. This is > goodness but not enough for the above requirement.
> Have I missed anything or will I need to be super-patient on this?
I've been looking for a PaaS provider with the same requirements as well, and haven't had much luck. I've tried appFog, Heroku, no.de (when it existed), and Nodejitsu and they all limit you to 1 (randomly assigned) http/s port.
However, it's very easy to get node running on a vanilla Joyent or AWS instance these days, and you can have all the ports you want. I'm currently doing this, and it's really not that hard to manage.
@Tomasz - can you talk more about your experiences using Azure?
On Tuesday, November 6, 2012 9:34:06 PM UTC-8, Tomasz Janczuk wrote:
> You can listen on a TCP port to process arbitrary (non-HTTP) traffic using > WIndows Azure Cloud Services. There are two varieties: Web Role and Worker > Role. You need Worker Role. You can set up several instances and have > Windows Azure load balance traffic between them. Check out the tutorial at > https://www.windowsazure.com/en-us/develop/nodejs/tutorials/getting-s... > .
> On Tuesday, November 6, 2012 12:50:32 AM UTC-8, paul_tanner wrote:
>> Hi,
>> We have developed a webserivce built in node that susbcribes to TCP >> sockets to get realtime input.
>> Having got excited about switching from dedicated severs to PaaS I >> seem to have hit a brick wall in that non-http ports are not yet >> supported on those I've looked at.
>> This is a shame because quite a large class of apps are ruled out >> while this restriction remains.
>> I hear that websockets will be supported real soon now. This is >> goodness but not enough for the above requirement.
>> Have I missed anything or will I need to be super-patient on this?
The problem these PaaS providers face is that http (and even https with
SNI) allow you to route incoming requests by hostname on a single IP
address.
Other TCP services (generally) do not allow this, forcing the provider to
give you a unique IP address. This is relatively straightforward for
someone like Amazon who have several /15s available to them (131k IP
addresses each), but much more complicated for other PaaS providers.
On Wed, Nov 7, 2012 at 11:58 AM, Evan <evantah...@gmail.com> wrote:
> I've been looking for a PaaS provider with the same requirements as well,
> and haven't had much luck. I've tried appFog, Heroku, no.de (when
> it existed), and Nodejitsu and they all limit you to 1 (randomly assigned)
> http/s port.
Yep, but there are interesting ways to do things still, like STUN and SOCKS bindings if you have a proxy of your own out there you can generally setup the tunnel inside most PaaS. Generally though the PaaS is stuck to preallocating port/host pairs and charging for them since most don't give you a full fledged IP.
On Wednesday, November 7, 2012 12:27:29 PM UTC-6, Matt Sergeant wrote:
> The problem these PaaS providers face is that http (and even https with > SNI) allow you to route incoming requests by hostname on a single IP > address.
> Other TCP services (generally) do not allow this, forcing the provider to > give you a unique IP address. This is relatively straightforward for > someone like Amazon who have several /15s available to them (131k IP > addresses each), but much more complicated for other PaaS providers.
> On Wed, Nov 7, 2012 at 11:58 AM, Evan <evant...@gmail.com <javascript:>>wrote:
>> I've been looking for a PaaS provider with the same requirements as well, >> and haven't had much luck. I've tried appFog, Heroku, no.de (when >> it existed), and Nodejitsu and they all limit you to 1 (randomly assigned) >> http/s port.
Well I work for Microsoft, so you can only imagine my experience using Azure just cannot be bad ;). But seriously, there are several ways of running node.js code in Azure: - you can own a VM (Windows or Linux), where you can listen on whatever TCP port you please and have the traffic load balanced between VMs that form a cluster, - you can run node.js apps in a so called Cloud Service. Cloud Service differs from a raw VM in that your app is managed for you (Azure will detect when it died and restart a new instance; Azure will also patch the OS for you when necessary; all while ensuring that at least one instance of your app is always running). Cloud services come in two flavors: Web Role and Worker Role. In a Web Role your node.js app is hosted in IIS using https://github.com/tjanczuk/iisnode, and effectively restricted to HTTP. In a Worker Role you have a similar flexibility as in raw VM in terms of listening on arbitrary TCP ports using whatever protocols you want - and this was my suggestion for addressing this particular scenario. Azure can load balance traffic across multiple instances of a Cloud Service. - you can host your node.js app in Windows Azure Web Sites. This method runs your app in a shared hosting environment in IIS using https://github.com/tjanczuk/iisnode, which again restricts the protocol to HTTP(S). Windows Azure Web Sites have several advantages over Web Roles, most notably git based deployment, and a free offering.
You can deploy node.js apps to Windows Azure VM or Windows Azure Web Sites from whatever platform node.js runs on using the node.js-based CLI we have: run `npm install azure -g` and then call `azure` to get started. Yes, that includes Macs. Also make sure to check out https://www.windowsazure.com/en-us/develop/nodejs/.
On Wednesday, November 7, 2012 8:58:29 AM UTC-8, Evan wrote:
> I've been looking for a PaaS provider with the same requirements as well, > and haven't had much luck. I've tried appFog, Heroku, no.de (when > it existed), and Nodejitsu and they all limit you to 1 (randomly assigned) > http/s port.
> However, it's very easy to get node running on a vanilla Joyent or AWS > instance these days, and you can have all the ports you want. I'm > currently doing this, and it's really not that hard to manage.
> @Tomasz - can you talk more about your experiences using Azure?
> On Tuesday, November 6, 2012 9:34:06 PM UTC-8, Tomasz Janczuk wrote:
>> You can listen on a TCP port to process arbitrary (non-HTTP) traffic >> using WIndows Azure Cloud Services. There are two varieties: Web Role and >> Worker Role. You need Worker Role. You can set up several instances and >> have Windows Azure load balance traffic between them. Check out the >> tutorial at >> https://www.windowsazure.com/en-us/develop/nodejs/tutorials/getting-s... >> .
>> On Tuesday, November 6, 2012 12:50:32 AM UTC-8, paul_tanner wrote:
>>> Hi,
>>> We have developed a webserivce built in node that susbcribes to TCP >>> sockets to get realtime input.
>>> Having got excited about switching from dedicated severs to PaaS I >>> seem to have hit a brick wall in that non-http ports are not yet >>> supported on those I've looked at.
>>> This is a shame because quite a large class of apps are ruled out >>> while this restriction remains.
>>> I hear that websockets will be supported real soon now. This is >>> goodness but not enough for the above requirement.
>>> Have I missed anything or will I need to be super-patient on this?
