I am having problems getting Chromium/Firefox to handshake with my node.js install since they both use the hybi10 protocol now (which node WebSocket apparently doesn't support yet).
Am I right in thinking that doing...
new WebSocket( 'ws://127.0.0.1:8000','draft-ietf-hybi-00' );
... should force the browser to use an older protocol? It doesn't seem to solve my problem
No. The second argument is a sub-protocol and not related to the version of the WebSocket protocol being used by the browser. Each browser implements a single version of the WebSocket protocol. Servers often implement support for multiple protocol versions.
Perhaps the Node 'ws' module might work for you. There is also Socket.IO which is higher level communication library that uses WebSockets if it can but includes fallbacks if the WebSocket transport is not available.
Related
I am trying to test sip capabilities of firewalls using webrtc. However I noticed using the servers needed for webrtc (stun turn websockets etc.) will give me a false positive in that it won’t catch nuanced issues with the ALGs. For reference this is being done from a chrome app so I can’t just run a native sip stack in the browser.
My Question: can I leverage webrtc to just send sip(invite, options, register) and not use any other methods that would get around the firewall?
Your question doesn't make sense because WebRTC doesn't use SIP - SIP is a signaling protocol, and WebRTC doesn't do signaling. What that means is that SIP can be used to establish a WebRTC connection, but they are mutually exclusive.
SIP is sent over a data connection, like a hard line from a phone to a PBX or a websocket from a browser to a server.
It is possible to set up a WebRTC connection using out of band mechanisms, but then that wouldn't be SIP.
Actually there might be a way around that.
Use the signalling server to to do any sort of preconfigurations you might want to do before setting up the peer connection. This would allow you to specify codecs and resolution of the feed as a SessionDescription before hand or even check if the other peer is capable of WebRTC or not.
I'd recommend Socket.io =D
I have a SignalR 2.0 server hosted in IIS7 with a javascript client, targeting mainly Chrome browsers at the moment.
Without cross-domain, the SignalR transport is Server Sent Events, which works very nicely and is efficient.
I added CORS support to the server in the suggested fashion, using Microsoft.Owin.Cors -- that makes the server work with the client cross domain-- however, the SignalR transport is now long-polling; this is going to cause a much higher load on my servers, as the SignalR messages from the server to the client are quite frequent.
I'd really like to get Server-Sent Events and CORS support working together, and from my understanding of the protocols I don't see a reason why it can't be done. Any suggestions? Anyone have any luck in the same scenario with other browsers?
SignalR currently doesn't try to establish cross-domain SSE connections by default.
This decision was made before browsers had CORS compatible EventSource implementations, so it was seen as wasteful to even attempt establishing cross-domain SSE connections.
Starting with SignalR 2.0.3, cross-domain SSE connections will be attempted by default.
In the meantime you can manually specify which transports to try and what order to try them in:
$.connection.hub.start({transport: ["webSockets", "serverSentEvents", "foreverFrame", "longPolling"]});
http://www.asp.net/signalr/overview/signalr-20/hubs-api/hubs-api-guide-javascript-client#transport
can HTML5 communicate with Java Serversocketchannel?
if possible can anyone tellme the details.
thank you in advance.
I'm assuming that you are talking about WebSockets and not some other protocol (Flash, Java applet and Silverlight native sockets, or XMLHttpRequest connections). WebSockets are an HTTP family spec from IETF and not related directly to HTML5 (though they are both in the extended family of next-gen web standards).
Browser WebSocket implementations can only talk to servers that deliberately support the WebSocket protocol. You can certainly write a server that supports the WebSocket protocol using a ServerSocketChannel, but WebSocket will not be able to connect to an arbitrary service that was written (using ServerSocketChannel or not) without the WebSocket protocol in mind.
This is a deliberate security measure to prevent web browsers being forced to connect to non-web-related services (eg to port 25 to send spam).
If you want to write a WebSocket protocol layer on top of ServerSocketChannel you'll need to put a non-trivial amount of work into implementing the spec. It would seem more sensible to re-use an existing library.
I'm currently trying to get a simple client \ server websocket demo up and running and I'm trying to use the C# Nugget project as my server. I can connect to the server through Netscape (v5.1.4) but not through Chrome (v18.0.1) and I've tracked the issue down to the client handshake.
Nugget expects the client handshake to be in the following format which is exactly how Netscape is sending it:
Chrome's client handshake on the other hand is looking like this:
I've highlighted the differences in the two requests that are causing the problem in Nugget server - the sec-websocket parameters.
I'm guessing that Netscape and Chromes implementation of the client handshake are based on different versions of the websocket specification. Has anyone got any more information on this? Is it OK to just add code to handle both types of handshake or is one deprecated?
Any insights welcome,
James
Resources: Understanding Websocket Client Handshakes
It looks like Netscape is speaking the older, deprecated, Hixie variant of the protocol. Safari also uses this. Chrome uses the more modern RFC 6455. You can expect all browsers to use RFC 6455 eventually.
Assuming you want to support as many client types as possible, its okay (indeed correct) to add code to handle both variants. Note that the data framing for post-handshake reads/writes also changes depending on the protocol variant being used.
I am aware that an early draft of HTML5 specified peer-to-peer connections using the PeerToPeerConnection() constructor. However, this was replaced by WebSocket which, to my knowledge, does not support peer-to-peer connections.
In addition, the device element specifies a peer-to-peer connection interface, however no web browsers have implemented it yet.
Opera Unite allows Peer to peer (basically gives your browser web server, file system and nat-traversal capabilities), but this is Opera only.
It's not exactly P2P, but you can use proxy server using push mechanism
http://en.wikipedia.org/wiki/Push_technology
For example if you want to send data from Browser A to Browser B, you send that data to proxy server and that server push it to Browser B.