Can a WebSocket client written in java connect with phpwebsocketserver? Or do you have to have both client and server implemented in the same language?
Thanks.
Yes and no. The WebSocket protocol is still being discussed/modified. This has resulted in some incompatibilities among different implementations (for instance, different opcode numbers). That said, many implementations are compatible with eachother. Once the protocol is standardized, all compliant websocket implementations will be able to communicate with eachother regardless of language.
A socket is a socket. It doesn't matter what languages the server or client is implemented in, just as long as they can use sockets.
It doesn't matter what languages the clents and servers are written in. Messages are passed between the two. All that matters is that message format and header content conform to the websocket protocol.
Related
In the absence of a signalling server for coordinating the initial exchange, does WebRTC provide any way to allow the responder to send information freely to the caller, if the responder has only received an offer and has no other methods of communication with the caller?
(There's no signalling server because the web app must be useable offline. Any method to establish a connection with only one exchange of information would also be useful.)
Sorry, it's a long and weird question.
I guess by offline you mean that you have two parties that will connect through a network not connected to the internet.
Signaling is just a way to transmit information between the two parties. For the sake of example it can even be manual copy and paste. Even one of the parties can play the role of a server if the other one has a way of connecting to it (doable within the same network).
Without some kind of signaling mechanism, a WebRTC connection is not possible. And signaling is not part of the WebRTC specification, nor of any implementation.
Webrtc needs a signalling system for establishing peer to peer connection. Now the thing to notice is why it needs signalling.
In the process of establishing peer connection the two parties exchange sdp which contains information such as the IP and Port at both ends at which the media/data packets will get exchanged. Similarly it contains the encoding/decoding or codec to be used plus many other useful things.Thus without the exchange of these packets between both the parties any communication can't be possible.
That is why it is not possible at least in case of webrtc that without the communication from both sides a peer connection can be established.
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 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.
Will the Websocket Api implementation of HTML5 make node.js irrelevant? If not, what are the differences between the two ans where to use what?
Node.js is a server side, event based, asynchronous I/O framework.
HTML5 WebSockets a pretty much TCP sockets in the Browser, that's all they don't di much more then establishing a two way channel of communication.
For example, you would write your game Server with Node.js and then use WebSockets to communicate between your Browser based client and the server.
An example of such a Game (disclaimer, I'm the author of the project):
http://github.com/BonsaiDen/NodeGame-Shooter
To get an idea what Node.js does, I recommend that you watch some talks that are listed on our Node.js tag wiki.
Actually, WebSockets makes Node far more applicable; a good number of the interesting server side implementations of WebSockets use Node.
In fact, a library that is growing very fast in popularity is Socket.IO. Socket.IO is a server-side (Node) and client side library that allows you to rapidly create interactive web applications. The client and server coordinate to pick the best communication mechanism available to both (WebSockets is the preference but falls back to long-polling). The client and server side Javascript library interface is very similar (and both are Javascript) so it's very easy to create web applications quickly.