5 ms·

WebTCP: Making TCP Connections From Browser

50 points by yankoff 14y ago

chewxy 14y ago
So, TCP over HTTP, which is a protocol built on top of TCP. Does anyone see that this is rather silly? If you want a client-side app that uses TCP, why must you do it over the web? The appeal of write-once-run-everywhere?
- yankoff 14y ago
  Well, you didn't read the post apparently and only a title :(
  - chewxy 14y ago
    I actually did. I was quite interested in the redis example. For about 10 seconds, which I then went "wtf is this useful for?" We really need to stop reinventing the wheel
    - yankoff 14y ago
      What would you use to achieve the same thing with Redis?
      - sebastianmck 14y ago
        The XY Problem http://www.perlmonks.org/index.pl?node_id=542341 http://www.perlmonks.org/index.pl?node_id=542341
      - chewxy 14y ago
        I wouldn't. I'd make a HTTP call to the server, and let the server handle it. (i.e. your "what's so different from the backend method")?
        yankoff 14y ago
        Yep, and i wrote about differences to such approach in the post. Don't get me wrong, this is definitely a hack, I'm not saying people should stop doing it the old way.
        chewxy 14y ago
        Likewise. While I appreciate the concept of a bridge (I'm a strong believer that the fastest app is the app that does practically nothing at all, and I can see the benefit of using a TCP-bridge like thing to make something faster), I just think we should not be reinventing the wheel. That is to say, if you need a TCP connection to any server, you probably should not be implementing it over HTTP (well, this is where definitions get difficult, since you know, HTTP is technically TCP. Fuck)
      - lttlrck 14y ago
        REST is far more appropriate for databases. Pub/sub is well catered for by socket.io (websockets). This glue belongs on the server. If I did need arbitrary TCP connections my first thought would be a websocket proxy...
- khakimov 14y ago
  it's not about pure tcp, as i get it - it allows you communicate from browser directly (via webtcp server as a bridge) with any servers such as redis, mongodb, rabbitmq and so on. WebBrowser --- data ---> WebTCP bridge (translate data to servers) --- data ---> redis/rabbitmq/any_tcp(and i think udp also possible?)_server_even_smtp
- sneak 14y ago
  It's not TCP over HTTP, that would require a TCP stack. It's the io bytestream from a specific TCP connection, shuttled over HTTP. It's not entirely bogus, just mostly so. I really dislike this whole "the internet == the web" way of thinking, though.
  - javajosh 14y ago
    On the contrary, this sort of things allows us to write clients in a uniform way. It will be nice to be able to debug the redis client in a jsfiddle. :)
    - sneak 14y ago
      By this argument, "uniformity" means we should then port the linux kernel to javascript so that we can debug it in jsfiddle. Down that path lies madness.
      - javajosh 14y ago
        What's wrong with writing a kernel in JavaScript? This would actually be quite valuable as a pedagogical tool.
- icebraining 14y ago
  It uses Websockets, which are only HTTP for the handshake: the rest of the connection is just a TCP stream. So it's really more like a NAT bridge.
flux_w42 14y ago
I think this is a great idea. From the moment I heard of WebSockets I was disappointed it was only a thing between the sockets-capable-web-server and the client and not a real TCP connection to wherever you want. This solves stuff :) However, I think that you should keep an eye on the possible security implications (ex. fooling the same origin policy, using your websockets proxy as a hub to attack other systems on the internet, ...)
- dwj 14y ago
  Doesn't websockify do this better?
  - yankoff 14y ago
    It looks like with websockify you have to run a server with their wrapper to make it work
    - dwj 14y ago
      It looks like this also requires a server with a wrapper. The difference is that websockify is more efficient.
- 0x0 14y ago
  Isn't the major benefit of WebSockets that is actually has a fair chance to pass through all the crazy proxies and gateways installed in every office, home and coffe shop, that would otherwise filter any non-HTTP traffic?
- lttlrck 14y ago
  So make a websocket proxy...
y0ghur7_xxx 14y ago
This is an awesome hack. We really need real TCP connections from the browser. Until then this looks like a great workaround. I eagerly await the day we can use the browser for everything we do (did?) with Desktop apps.
- angersock 14y ago
  We built a simple proof-of-concept library that lets you use a web app as the GUI for native code, if anyone would be interested.
  - lisper 14y ago
    Yes please!
cstejerean 14y ago
This is definitely a cool hack, but please be mindful of the security considerations of deploying something like this on the internet. Running an open proxy that allows any client to perform arbitrary TCP connections bouncing through your servers is a bad idea. First, you need to worry about the security implications of each internal server that you expose intentionally. Just how much damage can someone with direct access to your Redis instance cause? Better read http://redis.io/topics/security http://redis.io/topics/security, and repeat this for every other service you want to expose. Second, you are going to effectively need a whitelist of allowed connections, either in the proxy, or at the firewall level (which most people are going to forget to configure, if they even know how). Without that you are going to allow arbitrary bypass of your firewall for internal services, as well as effectively running an open proxy for anyone looking to bounce their malicious traffic through your server.
- aidenn0 14y ago
  Yeah, just look at all the havoc caused by anonymous FXP in the '90s
eungyu 14y ago
Nice hack (although I would put this in the category of 'workaround'). The idea is cool, but I can already imagine all sorts of debugging nightmares with this approach. To begin with, how do we find out where the connection is broken (Is it the client socket or the proxy socket)? Bad connections have different reasons (in C terms: ECONNRESET, EWOULDBLOCK, ENETUNREACH, etc); are these specific reasons propagated verbatim? What about flow control between proxy and client? There is always a chasm between whipping up a cool hack and making something usable. This hack needs a long bridge in between.
drblast 14y ago
This is just what I need to complete the in-browser app I'm building to navigate and read these new hypertext pages I'm creating. I've developed a markup language that will let you reference any of these documents from any other. The app that lets you view them is going to work in any browser that supports WebTCP, too, for the ultimate in cross-platform compatibility!
seats 14y ago
If more web services supported CORS, pure client side apps would be way easier to do and less kludgy than via proxy. http://en.wikipedia.org/wiki/Cross-origin_resource_sharing http://en.wikipedia.org/wiki/Cross-origin_resource_sharing
smagch 14y ago
You may want to take a look at browserver http://news.ycombinator.com/item?id=4366555 http://news.ycombinator.com/item?id=4366555 http://browserver.org/ http://browserver.org/
saljam 14y ago
Chrome (and I believe Firefox too) has a TCP socket API, but it's only exposed to Chrome apps and extensions.

50 points by yankoff 14y ago

So, TCP over HTTP, which is a protocol built on top of TCP. Does anyone see that this is rather silly? If you want a client-side app that uses TCP, why must you do it over the web? The appeal of write-once-run-everywhere?

yankoff 14y ago
Well, you didn't read the post apparently and only a title :(
- chewxy 14y ago
  I actually did. I was quite interested in the redis example. For about 10 seconds, which I then went "wtf is this useful for?" We really need to stop reinventing the wheel
  - yankoff 14y ago
    What would you use to achieve the same thing with Redis?
    - sebastianmck 14y ago
      The XY Problem http://www.perlmonks.org/index.pl?node_id=542341 http://www.perlmonks.org/index.pl?node_id=542341
    - chewxy 14y ago
      I wouldn't. I'd make a HTTP call to the server, and let the server handle it. (i.e. your "what's so different from the backend method")?
      - yankoff 14y ago
        Yep, and i wrote about differences to such approach in the post. Don't get me wrong, this is definitely a hack, I'm not saying people should stop doing it the old way.
        chewxy 14y ago
        Likewise. While I appreciate the concept of a bridge (I'm a strong believer that the fastest app is the app that does practically nothing at all, and I can see the benefit of using a TCP-bridge like thing to make something faster), I just think we should not be reinventing the wheel. That is to say, if you need a TCP connection to any server, you probably should not be implementing it over HTTP (well, this is where definitions get difficult, since you know, HTTP is technically TCP. Fuck)
    - lttlrck 14y ago
      REST is far more appropriate for databases. Pub/sub is well catered for by socket.io (websockets). This glue belongs on the server. If I did need arbitrary TCP connections my first thought would be a websocket proxy...
khakimov 14y ago
it's not about pure tcp, as i get it - it allows you communicate from browser directly (via webtcp server as a bridge) with any servers such as redis, mongodb, rabbitmq and so on. WebBrowser --- data ---> WebTCP bridge (translate data to servers) --- data ---> redis/rabbitmq/any_tcp(and i think udp also possible?)_server_even_smtp
sneak 14y ago
It's not TCP over HTTP, that would require a TCP stack. It's the io bytestream from a specific TCP connection, shuttled over HTTP. It's not entirely bogus, just mostly so. I really dislike this whole "the internet == the web" way of thinking, though.
- javajosh 14y ago
  On the contrary, this sort of things allows us to write clients in a uniform way. It will be nice to be able to debug the redis client in a jsfiddle. :)
  - sneak 14y ago
    By this argument, "uniformity" means we should then port the linux kernel to javascript so that we can debug it in jsfiddle. Down that path lies madness.
    - javajosh 14y ago
      What's wrong with writing a kernel in JavaScript? This would actually be quite valuable as a pedagogical tool.
icebraining 14y ago
It uses Websockets, which are only HTTP for the handshake: the rest of the connection is just a TCP stream. So it's really more like a NAT bridge.

flux_w42 14y ago

I think this is a great idea. From the moment I heard of WebSockets I was disappointed it was only a thing between the sockets-capable-web-server and the client and not a real TCP connection to wherever you want. This solves stuff :) However, I think that you should keep an eye on the possible security implications (ex. fooling the same origin policy, using your websockets proxy as a hub to attack other systems on the internet, ...)

dwj 14y ago
Doesn't websockify do this better?
- yankoff 14y ago
  It looks like with websockify you have to run a server with their wrapper to make it work
  - dwj 14y ago
    It looks like this also requires a server with a wrapper. The difference is that websockify is more efficient.
0x0 14y ago
Isn't the major benefit of WebSockets that is actually has a fair chance to pass through all the crazy proxies and gateways installed in every office, home and coffe shop, that would otherwise filter any non-HTTP traffic?
lttlrck 14y ago
So make a websocket proxy...

y0ghur7_xxx 14y ago

This is an awesome hack. We really need real TCP connections from the browser. Until then this looks like a great workaround. I eagerly await the day we can use the browser for everything we do (did?) with Desktop apps.

angersock 14y ago
We built a simple proof-of-concept library that lets you use a web app as the GUI for native code, if anyone would be interested.
- lisper 14y ago
  Yes please!

cstejerean 14y ago

This is definitely a cool hack, but please be mindful of the security considerations of deploying something like this on the internet. Running an open proxy that allows any client to perform arbitrary TCP connections bouncing through your servers is a bad idea. First, you need to worry about the security implications of each internal server that you expose intentionally. Just how much damage can someone with direct access to your Redis instance cause? Better read http://redis.io/topics/security http://redis.io/topics/security, and repeat this for every other service you want to expose. Second, you are going to effectively need a whitelist of allowed connections, either in the proxy, or at the firewall level (which most people are going to forget to configure, if they even know how). Without that you are going to allow arbitrary bypass of your firewall for internal services, as well as effectively running an open proxy for anyone looking to bounce their malicious traffic through your server.

aidenn0 14y ago
Yeah, just look at all the havoc caused by anonymous FXP in the '90s

eungyu 14y ago

Nice hack (although I would put this in the category of 'workaround'). The idea is cool, but I can already imagine all sorts of debugging nightmares with this approach. To begin with, how do we find out where the connection is broken (Is it the client socket or the proxy socket)? Bad connections have different reasons (in C terms: ECONNRESET, EWOULDBLOCK, ENETUNREACH, etc); are these specific reasons propagated verbatim? What about flow control between proxy and client? There is always a chasm between whipping up a cool hack and making something usable. This hack needs a long bridge in between.

drblast 14y ago

This is just what I need to complete the in-browser app I'm building to navigate and read these new hypertext pages I'm creating. I've developed a markup language that will let you reference any of these documents from any other. The app that lets you view them is going to work in any browser that supports WebTCP, too, for the ultimate in cross-platform compatibility!

seats 14y ago

If more web services supported CORS, pure client side apps would be way easier to do and less kludgy than via proxy. http://en.wikipedia.org/wiki/Cross-origin_resource_sharing http://en.wikipedia.org/wiki/Cross-origin_resource_sharing

smagch 14y ago

You may want to take a look at browserver http://news.ycombinator.com/item?id=4366555 http://news.ycombinator.com/item?id=4366555 http://browserver.org/ http://browserver.org/

saljam 14y ago

Chrome (and I believe Firefox too) has a TCP socket API, but it's only exposed to Chrome apps and extensions.