I'm working with NodeJS and found this code that implements kind of native support for sockets since NodeJS doesn't supports sockets by default.
So I used the code to open a server(server is waiting...), now for the client side I used some simple html file on my desktop with code like that, well at first glance it fail, but when I debug the code a bit I found out the the NodeJS socket code I found needs sec-websocket-key1 and sec-websocket-key2 while I get from the client-side code I implemented(in the plnkr) only sec-websocket-key.
I looked that up and found that link that saying:
The first protocol used by HTML5 WebSockets was
draft-ietf-hybi-thewebsocketprotocol-00 (HyBi 00). All was well until
the protocol was upgraded to remedy some security issues. As a result
of these changes, the Sec-WebSocket-Key1 and Sec-WebSocket-Key2 fields
were added to the client header.
Basically that explains why I get sec-websocket-key, I know that article also say that(according to caniuse) there only 2 browser supports the latest websockets protocol, I tested with chrome and firefox and both sends the same sec-websocket-key...
What is the true protocol I should support(is the right one), the one used web-socket-key1/2 or just sec-websocket-key
Which browsers supports(if those should be supported) sec-websocket-key1 and sec-websocket-key2?
Am I doing something entirely wrong with my client-side Web Sockets or the server side?
Is there a shim to fix something?
The article is several years old and describes version 6 of the protocol, which was still only a draft is now long obsolete. The current version is 13 and is described in RFC 6455. And this is the version you will find implemented in all current browsers.
Thus it is best to simply ignore the article or only see it in a historical context. For any new implementation please refer to the RFC only and not to any previous drafts.
I know that article also say that(according to caniuse) there only 2 browser supports the latest websockets protocol,
Looking at caniuse shows that all current browsers support the relevant version of Websockets.
since NodeJS doesn't supports sockets by default.
This question from 2013 has an overview of several implementations. I'm pretty sure that widely used implementations like Socket.IO support the latest version of the protocol.
Related
I have a project which needs live updates on certain parts of the website, this done with websockets. On other parts of the site I use POST/GET. I just came to think of it, is there any reasons not to use only websockets? What could I gain/loose by dropping POST/GET?
Browser support for Web Sockets is good in current versions. But the answer very much depends on your project.
You'll have to manage the websocket, in case it closes unexpectedly. A GET/POST is easier in that regard. You can just set an interval and if one goes missing, there's always the next request.
If it's not a critical feature, and if your audience is skewed towards chrome/firefox/safari, and your websocket implementation is solid already, i'd drop GET/POST.
Personally I think the biggest disadvantage would be browser support. Websockets have great support in Chrome and Firefox but only recently came to Internet Explorer. By completely relying on websockets unless you had a fallback you'd be cutting off some older/mobile browsers.
As kidshenlong already mentioned, the biggest problem would be browser support. You should also consider, though, that an open websocket uses up resources (mostly memory) on your server for each client that is currently connected.
I have an embedded system which is running the LwIP server(v1.2), I need to be able to stream a data array into the javascript on the client side? I'm looking at using chrome and some HTML5 features, so some people have suggested using websockets. Does anyone know where I need to start to use these with the LwIP framework? Any help at all would be much appreciated!
WebSockets is a relatively simple protocol so you could use the protocol spec and write your own server. Since lwIP offers a bsd sockets API, you could also search for existing open source C servers. (A quick search shows up this candidate for instance. BTW, note that this code licensed as GPL. You should only use it if you understand the requirements using GPL'd code puts on your project.)
Note that while Chrome support for websockets is good, support is patchier if you later decide to use other browsers (and particularly to allow users with older browsers). See here for details. If support for a variety of browsers matters to you, you'll probably have to include code in client and server to fallback to long polling when a websocket handshake fails.
There is a javascript code residing in my Android app's webkit container. This code makes use of WebSockets to communicate with the server. The same JS code works in other platforms such as iOS, but in Android 2.3, it doesn't. I read somewhere that the webkit in Android does not support WebSockets, and support will come only in Jelly Bean onwards.
In view of this, I need to provide a wrapper from the native layer (in Java) making use of plain sockets. From the little I know about sockets, it seems straightforward to support the usual APIs such as open(), send(), receive(), etc.
Is there anything else I need to know that the WebSocket protocol needs, which I will need to provide from the wrapper code? After all, the server talks to the client (my android app) as if it is a WebSocket, and not a native socket.
Some notes to consider: a) I cannot make use of any third-party library - it will have to be developed in-house. b) There will not be any binary data transferred; only text.
Thanks,
Rajath
Websockets are not raw sockets, they require an initial handshake then simple per-message framing. See the protocol spec for details. The sections on handshake and data framing will be most relevant.
I know you said you can't use third party libraries but be aware that projects like Java-Websocket might be interesting to you. It's liberally licensed so suitable for inclusion in any closed source app. Or you might find it useful as a reference while debugging your own code.
Is there any way to recognise pen pressure using javascript.
Preferably I don't want to make any use of Flash and try get this done as pure JS.
EDIT: okay I realised that it is kind of possible for Wacom tablets as they come with software that can work with their javascript api to make it possible (demos). But it's no good for people with Trust tablets or any other brand... So no good really.
Any body know how to do it in C# if not JS?
Yes - if the user has a Wacom tablet installed, then their browser will have a plugin for it that you can access. http://www.wacomeng.com/web/index.html
edit from author: I wrote this a very long time ago. Please see the comments below
Microsoft implemented something called Pointer Events in IE 11. It allows you to access pressure property along with stuff like pen tilt and size of contact geometry.
So far it only works on IE11 (and IE10 with vendor prefixes) but there is a W3C candidate recommendation so maybe it will be standard in future.
Javascript as a programming language in itself has no more ability or lack of ability to read this kind of data than any other language.
The language isn't important. What is important are the APIs available to you from within the language.
Javascript can be run in a number of different environments, some of which may possibly have access to APIs for this kind of hardware. However most Javascript is run in a web browser environment, and this is clearly what you mean.
The web browser environment provides a number of APIs. The most obvious is the DOM, which gives you the ability to manipulate the page, etc. There are other APIs available in the browser as well though. For example, the Geolocation API.
All these are standard APIs which have been defined by the W3C (or in some cases are in the process of being defined by the W3C), meaning that all browsers that support them should make them work the same way.
Unfortunately for you there isn't a standard API for working with pressure pads, so the direct answer to your question is no, it can't be done.
Whether one will become available in the future remains to be seen, but I have my doubts.
There is one way that you can do it though: ActiveX.
ActiveX is an API provided by Microsoft in older versions of IE. It basically provides a way of accessing virtually any Windows DLL code from within the browser.
Since the pressure pen device driver for Windows will be provided as a DLL, this means you should theoretically be able to access it in the browser via an ActiveX control. So therefore yes, you would be able to program it using Javascript.
The bad news, though, is that this is not something I'd recommend. ActiveX as a browser-based technology has long since been abandoned, due to the massive security holes it caused. I don't think the latest versions of IE even support it (I hope not, anyway), which means you'd be forced to use old versions of IE (and only IE - no other browser ever supported it) in order to run your code. Not ideal.
No, that's not possible. Probably not even with Flash.
You can only do so in an Native app. Javascript does not have access to pen pressure information
I need to deal with breaking connections and other standard things which are not handled by WebSockets yet. Something tells me that there must be plenty of plugins to do this. Do you use anything like that or write your own routines?
I need it for the client side, since I use Sinatra on the server side.
There are two common issues at hand: supporting older browsers that don't natively support WebSockets and automatic reconnect (in case of breaking connections).
Older browsers are supported by several vendors and products through emulation using different transports - what you need to look at is how good the emulation is. Here's a brief article on the topic describing the problem and Kaazing's solution [disclaimer: I work for Kaazing].
The Kaazing WebSocket Gateway also provides automatic reconnect - in case the connection breaks.
You can download the free developer version of the Kaazing Gateway - to give it a try.