I am trying to make myself familiar with websockets. It is possible to create tunnels with websockets
https://github.com/erebe/wstunnel
You can even tunnel VPN protocols like wireguard through it.
Would it be possible to use Chrome and Nginx in a similar way?
A websocket connection is established between both. A client uses the websocket of Chrome to funnel its traffic through the tunnel. On the nginx end data leaves the tunnel and gets forwarded to the internet.
Like: Client --> Chrome Websocket --> Websocket Tunnel --> Server --> Internet
Will this work in principle? Can clients (like other programs running on the machine or different devices on the network) use the websockets opened by Chrome? Is there a limitation on what the client can be? Are websockets standardized in a way that they are compatible (like a wstunnel client but nginx endpoint)?
Related
I built the server into Java,The server sends (image)data to the web browser through a web socket.So far it works fine.
and I wand that The web browser send data from the server to another web browser (client) using webRTC, So I looked for the webrtc...
I noticed that there are occasions when you need to use webSocket with webRTC
What is the role of websocket in webRTC?
In order to establish a WebRTC connection between two browsers, these browsers will have to negotiate a connection first. To negotiate a connection they need to be able to talk to each other. But they cannot talk to each other because they have not established a connection yet.
That's where a signalling server comes in. That's a server that both peers are already connected to and which can relay messages between them until they have established a connection. Using a websocket connection for this purpose is the most useful way, since it's a (soft) realtime bi-direction communication channel, exactly what you want when relaying messages as quickly as possible.
It doesn't have to be a websocket though; AJAX and/or long-polling will do too, but they have more overhead and are slower, which means it will take longer to negotiate the WebRTC connection.
In this way, the client can connect the server without ALPN and use http/2 default.
Is that possible？
Yes it is possible, but the conditions are strict.
Browsers, as of now, do not implement clear-text communication for HTTP/2, so if you use a browser the answer to your question is no: you have to deploy your server with ALPN support if you want browsers to be able to connect.
On the other hand, other clients such as Java clients may be able to connect to a server using clear-text HTTP/2, so for those type of clients the answer to your question is yes: you can deploy a HTTP/2 server without ALPN support.
The Jetty Project [disclaimer, I am a committer] implements a web server and servlet container that support both scenarios: you can enable ALPN for TLS (SSL) HTTP/2 communication so that browsers will be able to connect, and you can also enable clear-text HTTP/2 communication as explained here. See also the Jetty HTTP/2 documentation.
Which is best tcp socket server to testing html5websocket? I developing a html5socket based client that will interact with tcp. So I want first a testing server. I am good in PHP but not in sockets programming. So I used PHPwebsocket downloaded from google code. I tried it using its own client and server for testing but it suddenly disconnects and not work as intended so is there any other socket server to test HTML5 websocket client? Which one is better, I can use a python based, or java based tcp server or if in PHP then that can be more convenient. And please tell me what else I need to test HTML5 websocket. I am newbie in sockets. So my concepts are not so clear.
thanks for any advise.
If you want to self host then:
pywebsocket - Python
jwebsocket - Java
jetty with WebSockets - Java
You could connect to the Pusher hosted WebSocket API to see if you can connect. More information on the endpoints and Pusher protocol here:
http://pusher.com/docs/pusher_protocol
You would need to sign up for a free Pusher sandbox account to do this though.
You say you want to "interact with tcp". Do you have specific protocols in mind? If using JMS, XMPP, or AMQP, the Kaazing WebSocket Gateway provides these industry standard APIs and protocols in the browser out-of-the-box. For example, using JMS, you can build pretty complex messaging applications without a single line of server-side code. Everything can run in the client (typically in JavaScript in the browser).
Here are some examples showcasing the power of extending rich business protocols all the way to the browser.
Also, the Kaazing gateway comes with free development license; fully functional server for up to 50 concurrent connections, no functionality or time restrictions.
I already have a server with port and want to write a web app to get the information form the port. Will this be possible with WebPorts?
The Client doesn't even need to talk back to the server, which is the whole point of websockets I would imagine, but since I already have the ports setup, I might be easier and cleaner to just connect and get the info without having to refresh.
WebSockets are not intended as clear TCP channels over which other existing protocols can be implemented.
WebSockets are designed to allow messages to be sent between a client and server, where an event is raised each time a message is received.
Hence a WebSocket client cannot simply connect to an existing TCP server - that server also has to speak the WebSocket protocol.
You could of course write a WebSocket-based server that does nothing but act as a proxy to existing network services.
I think you want websockify which is a WebSocket to plain TCP socket bridge/proxy. It also allows sending and receiving of binary data with the older version of the WebSocket protocol which hadn't yet added direct binary data support.
Disclaimer: I created websockify.
I have a testapp consisting of an HTML5/WebSocket client and an HTTP/WS server. Both servers are in C#; the HTTP server is my own simple thing and the WS server is also homebrew based on concepts from http://nugget.codeplex.com/. HTTP server is listening on 0.0.0.0:5959 and WS server on 0.0.0.0:5960 (accept connections from any client, but on different ports).
My index.html includes some JavaScript that opens a WebSocket to 'ws://'+document.location.hostname+':5960/' (that is, to the same IP address that the webpage came from, but on port 5960). The WS server sends sample data every 100ms. All in all, it's a pretty straightforward demo.
I'm using Chrome 12.0 on Windows7.
I've found that the HTTP server works from any client, either a browser on my machine pointed to 127.0.0.1:5959 or localhost:5959, AND it works when any machine (mine or a remote machine... "remote" being a different PC on my desk :) hits my server machine's work-internal 10-net address 10.122.0.159:5959. Everything works as expected in HTTP land.
However, the WebSocket only works on 127.0.0.1 and localhost; remote machines can successfully fetch HTML from 10.122.0.159:5959 but the WebSocket will NOT connect to 10.122.0.159:5960. In fact, when I point my local browser to it's own 10-net address (10.122.0.159:5959) I get the same result - HTML loads but WebSocket does not connect.
Any ideas as to why this might be happening?
Does CORS require that the WS be using the same port as the HTTP request originated from? If so, is there a special exception to the rule for 127.0.0.1?
Many thanks,
-Dave
Update
It seems to be caused by a proxy server blocking ws:// requests. Our company employs a proxy server for content filtering and all the usual stuff, and our browsers are configured to use it.Chrome uses IE's proxy settings, and IE's default settings are for localhost to not use a proxy server. When I check the box to have local connections also use the proxy server, my ws:// requests to localhost get blocked. Conversely, when I uncheck the "use proxy server" box my server does rx the WS request. Similarly with the remote machine, if I turn off the proxy on the remote machine my server does rx the ws:// request.
So it's a proxy thing, not a CORS or socket thing, and now I'm off to explore proxy settings with our IT folks.
There is no WebSocket limitation on cross-origin except what is governed by the CORS security in the handshake.
It sounds like something is wrong with your WebSocket server and it is only listening on localhost for connections. I would add some debug output to the OnClientConnect routine in Nugget (WebSocketServer.cs) so you can see when socket connections happen. If you really think it isn't a problem with the server then I would suggest using wireshark and comparing the localhost connection to the remote connection.
Also, if you are using the SilverLight WebSocket prototype (README) in IE 9, then you are restricted to ports 4502-4534 for WebSocket connections. It's possible that for localhost this restriction is lifted.
It is/was indeed a proxy thing.
Rather than asking our IT folks to make changes (good luck with that, eh?) I simply turned off proxy for 10.122.0.159 ([Howto for IE/Chrome][1]). I briefly experimented with turning it off for the ws:// protocol but couldn't get it to work, so for now just opening that one IP address does the trick.