Is it possible to initiate a TCP connection from a browser?
If so, does there already exist browser (esp. Firefox and Chrome) extensions that do this? If no extensions exist yet, do you know the core elements/functions to create a Firefox/Chrome browser-initiated TCP connection?
The Chrome Browser (I think since v24 in the stable channel) lets you host a TCP server, and the samples indicate that it can connect to a telnet server, which means that it is also capable of being a TCP client.
https://github.com/GoogleChrome/chrome-app-samples/tree/master/tcpserver
https://github.com/GoogleChrome/chrome-app-samples/tree/master/telnet
But these are not standardized, so, if you can work with websockets, do prefer that.
http://developer.chrome.com/apps/socket.html
There are Websockets, but they are limited to the websocket protocol outlined at in RFC 6455.
So far, most modern webbrowsers support it
Related
i want to make TCP server with Node.js and then connect it from browser without http , express and socket.io moudles. something like what i do in java or c# but this time from browser.
The browser does not contain the capability for Javascript in a regular web page to make a straight TCP socket connection to some server.
Browser Javascript has access to the following network connection features:
Make an http/https request to an external server.
Make a webSocket connection to an external server.
Use webRTC to communicate with other computers
In all these cases, you must use the libraries built into the browser in order to initiate connections on these specific protocols.
There is no capability built into the browser for a plain TCP socket connection. A webSocket (which can only connect to a webSocket server) is probably the closest you can come.
For my academic project, I am trying to achieve this.
A web server node JS application listening on port 3000.
So If you curl http://localhost:3000 you will get Hello World!. ( A simple web page.
Now I am running above webserver in my local machine. And my modem is behind NAT. Suppose If I port forward in the modem to myip:3000 then it is open to the world. But here is the biggest thing I am stuck - I don't want to use the modem for port forwarding, instead, I will use third party server for UDP Punch Hole.
Now my requirement is anyone from net should able to access my webserver at curl http://third-party-server-ip:3000.
What I am trying is to write another client - which opens a connection to the third party server. Say it did a hole punching at port 41234. That port is open. The third-party host can send something to that port.
Now anyone in the internet initiate this command curl http://third-party-ip:3000 to the third party host. So the third party returns the myip:udpPunchHolePort i.e., myip:41234.
anyone will again curl to myip:41234 it will be received by the node js UDP punch app, so it will redirect to localhost:3000. Finally, the anyone will receive the response from localhost:3000.
My two questions -
Is there any better way than the one I proposed here?
Is there any well-known node-js lib for this kind of stuff, I see,
I can use UDP punch hole. Or I am thinking to write a Lib to do this in general - does this sounds like re-inventing the wheel?
Note -
In this academic project, we are trying to learn how to make any local application open to the world without port forwarding in the modem.
We read on skype protocol analysis, that is also our inspiration.
No, that won't work.
HTTP runs over TCP, not UDP. Punching a UDP hole doesn't do you any good -- any TCP connection to the backend HTTP server will still fail.
HTTP redirects are not magic. If a user cannot access a specific host:port, redirecting them to a URL on that host:port will just make their browser time out when it requests that URL.
You cannot send a response from a different host:port from what the browser requested, because there is no TCP connection established with that endpoint.
if you open a website and then follow a link within the same site trough opening it in an inkognito mode, do the browsers keep their connection on a tcp level (as they would per https://www.rfc-editor.org/rfc/rfc2616#section-8.1 ?
I've never heard about a standard about inconginto mode but browsers certainly should not reuse TCP connections from non-incognito mode in incognito one. I've just checked Firefox and Chrome. They open new TCP connections.
You can check it by yourself. Write a dump by Wireshark. Apply HTTP filter. Find a request. Apply "Follow TCP stream" context menu. You will see the whole TCP stream. It's easy to read.
I have made my personal project using WebSocket.
I already know that WebSocket will not connect directly raw TCP Socket.
so, I have thought what if I connect, at first, to Web Server(NodeJS) and then switch to TCP server.
is It possible to switch connection to another server using NodeJS?
If so.
Please let me happy.. Thank you! have a nice day.
I would assume it might be both possible and straightforward to tunnel/proxy TCP traffic. The high level design would be:
Start up a web server with integrated websocket server (use socket.io, really)
When a client makes a websocket connection, create an upstream TCP connection to your target server
Then do full bidirectional piping of messages between the browser<->node socket and the node<->otherServer socket
Devil might be in the details. I haven't tried, but seems feasible.
There's a node project called ws-tcp-bridge as well as a python project that claim to do this already. Neither luke terribly mature, but they might just work or at least provide good reference material.
I know p2p software like Skype is using UDP hole punching for that. But what if one of the clients is a web browser which needs to download a file from another client (TCP connection instead of UDP)? Is there any technique for such case?
I can have an intermediate public server which can marry the clients but I can't afford all the traffic between these clients go through this server. The public server can only establish the connection between the clients, like Skype does, and that's all. And this must work via TCP (more exactly, HTTP) to let the downloading client be a web browser.
Both clients must not be required to setup anything in their routers or anything like that.
I'll plan to code this in C/C++ but at the point I'm wondering if this idea is possible at all.
I previously wrote up a very consolidated rough answer on how P2P roughly works with some discussion on various protocols and corresponding open-source libraries. You can read it here.
The reliability of P2P is ultimately a result of how much you invest in it from both a client coding perspective and a service configuration (i.e. signaling servers and relays). You can settle for easy NAT traversal of UDP with no firewall support. Maybe a little more effort and you get TCP connectivity. And you can go "all the way" and have relays that have HTTPS listeners for clients behind the hardest of firewalls to traverse.
As to the answer of your question about firewalls. Depends on how the Firewall is configured. Many firewalls are just glorified NATs with security to restrict traffic to certain ports and block unsolicited incoming connections. Others are extremely restrictive and just allow HTTP/HTTPS traffic over a proxy.
The video conference apps will ultimately fallback to emulating an HTTPS connection over the PC's configured proxy server to port 443 (or 80) of a remote relay server if it can't get directly connected. (And in some cases, the remote client will try to listen on port 80 or port 443 so it can connect direct).
You are absolutely right to assume that having all the clients going through a relay will be expensive to maintain. If your goal is 100% connectivity no matter what type of firewall the clients is behind, some relay solution will have to exist. If you don't support a relay solution, you can invest heavily in getting the direct connectivity to work reliably and only have a small percentage of clients blocked.
Hope this helps.
PeerConnection, part of WebRTC solves this in modern browsers.
Under the hood it uses ICE which is an RFC for NAT hole-punching.
For older browsers, it is possible to use the P2P support in Flash.