Is there ever any situation where a Windows Store (i.e. Metro) app is allowed by the system to connect to a particular host via a WebSocket, but not to attempt a raw TCP connection to it?
-
Q1: Why *wouldn't* WebSockets be an option? Q2: Exactly which ["WebSockets"](http://www.paulbatum.com/2011/10/getting-to-know-systemnetwebsockets.html) are you referring to: .Net 4.5/System.Net.Websockets, Win-RT/Windows.Networking.Sockets, or HTML5/Javascript WebSockets? Here is an excellent article: http://msdn.microsoft.com/en-us/magazine/hh975342.aspx – paulsm4 Nov 02 '12 at 15:57
-
@paulsm4: Q1) it's an option but more complex than TCP, especially if you already have a server speaking a proprietary TCP-based protocol which would need updating to layer on top of WebSockets. Q2) the protocol specified by RFC-6455, via any system-provided API. – hmakholm left over Monica Nov 02 '12 at 16:02
-
@paulsm4: Though my understanding is that a Metro app is only ever allowed to use the Windows.Networking.Sockets one. – hmakholm left over Monica Nov 02 '12 at 16:05
-
rgd "server would need updating" for WS: FWIW, you can run a WS-to-TCP gateway (easy to do) .. that unwraps WS traffic merely forwarding the payload as raw TCP. I.e. here https://github.com/kanaka/websockify and as an application of the latter: a VNC client in browser => https://github.com/kanaka/noVNC . We have a generic TCP tunnel over WS done, to connect to PostgreSQL via WS, tunneling the native PG protocol, able to use any PG client. Like SSH-tunnel, but Web compatible. – oberstet Nov 02 '12 at 16:51
2 Answers
You are asking for "app is allowed by the system", but you should take into account not only the two endpoints involved (client, server), but also the network in between and any intermediaries like firewalls, proxies and the like.
Due to it's HTTP compatible initial handshake, a WebSocket connection is more likely to succeed than a raw TCP connection on some arbitrary port.
However, if you compare the success rates of a secure WebSocket connection on standard port 443, with a raw TLS/TCP connection also on port 443, those might be similar.
Usually, intermediaries won't be able to intercept, inspect or block TLS/443 .. if they want to allow HTTPS ..

- 21,353
- 10
- 64
- 97
-
Makes sense. I think I was implicitly comparing to a raw TCP connection on port 80/443, because that's what the product I'm working on already does -- we have special server instrumentation to separate those connections from actual HTTP(S) already. But you're right that this won't usually be an option in the general case I'm asking about. – hmakholm left over Monica Nov 02 '12 at 16:40
There's a nice blog on why someone would use websockets: http://lucumr.pocoo.org/2012/9/24/websockets-101/
and someone has posted on stackoverflow about the pro's and cons: WebSockets vs raw TCP sockets in Flash
Edit: the second post is to do with flash, but still has some meaning to it.
-
That explains what WebSockets **is**, but does not answer my question: **Is there ever any situation where a Windows Store (i.e. Metro) app is allowed by the system to connect to a particular host via a WebSocket, but not to attempt a raw TCP connection to it?** – hmakholm left over Monica Nov 02 '12 at 16:01