TCP Socket to Websocket?

Question

There are plenty of websocket -> socket wrappers around there (like websockify) but is there an opposite available out there? Specifically, I want to be able to connect to a TCP

Answer 1

I'm not entirely clear on what you're asking, but the WebSocket API applies mainly to the client side.

How you code the server-side script and what language you use to do so is entirely up to you. When coding your server-side script, you should be able to choose whether to use a TCP socket or not, etc.

Answer 2

I am not sure what u were looking for but in case that helps someone in the future I will write what I did to solve my problem.

My problem: I wanted to be able to host noVNC on my web application's server and I wanted non websocket vnc servers to be able to understand it without using websockify.

My solution: I used ws-tcp-bridge node.js module to bridge the websocket port<--lport> where the noVNC client would connect to with the vnc tcp server's host.

Example: This happens by running the following command from the vncserver's machine:

ws-tcp-bridge --method=ws2tcp --lport=5555 --rhost=127.0.0.1:5902

That way I was able to host a non websocket vncserver at port 5902 and connect with it via noVNC at port 5555.

Haven't tested this very much but works very well with x11vnc vnc server.

Answer 3

Bridging from WebSocket client to TCP server is a generic solution that encapsulates the lower level TCP protocol into the higher level WebSocket protocol. It allows browsers (or other websocket clients) to communicate with arbitrary TCP servers. Note that the the client (JavaScript) application must still be able to decode/encode the protocol that the TCP server speaks.

The reverse operation is not generic and would require a special framing of the messages from the TCP client application to the bridge so that the bridge would know how to encode the WebSocket messages to the TCP server. WebSockets is a message based transport while TCP is a lower-level streaming transport. The TCP transport layer does not have a concept of messages in the protocol itself so this has to be handled at a high layer. In other words, you will have to do almost as much work to enable your TCP client application to communicate with the bridge application as it would take to implementing the a WebSocket client directly in your application. Actually, it's probably less to implement directly, because there are already WebSocket client libraries available for most popular languages.

You won't be able to connect a pre-existing TCP client via the bridge to an existing WebSocket server without changing either the client and bridge (to add message boundary and opcode information) or you will need a special WebSocket server that ignores the WebSiocket message boundaries and treats the incoming data as a stream (with message parsing handled at a higher layer).

Perhaps you could give an use-case where you think this might be useful?

Disclaimer: I made websockify.