61 replies to this topic

[David Wisti]

If echo.websocket.org is not working. You can also use the above websocket chat client with the following in host:

node.remysharp.com:8001

Note that the above websocket server does not echo back the chat. You can use Google Chrome and connect to the Websocket server at:

http://html5demos.com/web-socket

Edited by David Wisti, 30 November 2011 - 03:44 PM.

[ShaunR]

I've really got the web-socket bug now

http://screencast.com/t/TqFOatnbfmC

(frame rate is due to Jing, not the apps)

[jgcode]

I've really got the web-socket bug now

http://screencast.com/t/TqFOatnbfmC

(frame rate is due to Jing, not the apps)

Nice mirror.

[ShaunR]

Nice mirror.

Yup. This is what she looks like, face-on.

[jgcode]

I would have been more impressed if you posted that as a SVG instead of a jpg

[lordsathish]

ShaunR, Will you be posting your fixed code

[David Wisti]

Wow that is a nice mirror! I've updated the Websocket code and wrapped everything into a class. Also updated the chat client and added in a chat server that echos back what you send. Still struggling with the close handshake and I'm not sure if its 100% yet.

Attached Files

•  WebSocket Chat.zip   347.79K   131 downloads

[Jon Kokott]

chorme "16.0.912.63 m" is immediately closing the connection, anyone got it to work?

[Jon Kokott]

I'm assuming that this information is correct for chrome:

http://tools.ietf.or...tocol-17#page-7
section 1.3

This says that the protocal uses a SHA-1 hash, whereas the example is using a MD5. I'll start with that is suppose.

[Jon Kokott]

So the connection is actually being established now (it was using the incorrect hash), but I get an error code 62 on the first write to the connection...

[ShaunR]

ShaunR, Will you be posting your fixed code

Not sure what you mean by "fixed code". But I won't be releasing it until the api is completed and tested (it's a bit of a mess at the mo'). I'm currently up to supporting Hybi 17, 10,8, 6 and 00 (looking at Hixie and auto negotiation now) and have a prototype library for exporting events and commands (i.e. for remote monitoring), but still need to figure out the reciprocal methods. And, (this'll surprise a few people) some of it is LVOOP. . Oh. And finally, you get events for errors, status, messages etc

[mje]

And, (this'll surprise a few people) some of it is LVOOP.

No way, say it's ain't so. In other news, the sky is still blue. Well on Earth anyways, most of the time...

I'm still pumped about this topic. Granted I got to spend zero time on implementing something like this this year (still very disappointed about that), but 2012 will be different. Yeah, that's it, different. What can I say, there's still a bit of foolish youthful optimism in me.

[ShaunR]

No way, say it's ain't so. In other news, the sky is still blue. Well on Earth anyways, most of the time...

I'm still pumped about this topic. Granted I got to spend zero time on implementing something like this this year (still very disappointed about that), but 2012 will be different. Yeah, that's it, different. What can I say, there's still a bit of foolish youthful optimism in me.

Yup. It's not as clean as I usually like (can't use polymorphic VI's with dynamic terminals) but I needed to maintain state on a per-connection basis. So this is one of the rare instances where it is the better choice. It won't happen again, I promise (Sky's always grey over here )

Edited by ShaunR, 20 December 2011 - 02:12 AM.

[David Wisti]

I'm currently up to supporting Hybi 17, 10,8, 6 and 00 (looking at Hixie and auto negotiation now)

I'm curious, why are you supporting older versions of the protocol? What is auto negotiation in Websockets?

[ShaunR]

I'm curious, why are you supporting older versions of the protocol? What is auto negotiation in Websockets?

Because (for example, currently) Chrome uses Hibi 10, Firefox uses Hybi 9, I.E 10 (will use) Hybi 10, IE.9 (with HTML5 Labs plugin) supports Hybi 6 and Safari (different flavours) supports Hixie 75,76 or Hybi 00.

The specs are still fluid and browsers are having difficulty keeping up. If it's to be robust, then really I have to support all of them and besides, some of my favourite stock tickers are still on the old versions

Auto-negotiation:
In the latest specs, there is a negotiation phase whereby the client requests a connection and the server replies back with the supported protocols. That's part of it (for the server). The other part is the brute force client connection whereby you iteratively try each protocol until one works. This is one of the reasons why I needed to move to a class since with multiple connections all (potentially) talking different protocols, the reads and writes need to switch on each call and maintain their state (i.e closed, connecting etc). Rather than writing a connection manager, it made sense to bundle that info with the class data. Besides. this is TCPIP over HTTP so performance is secondary

Edited by ShaunR, 20 December 2011 - 07:10 PM.

[smarlow]

Hello, Everybody, I am back!

I have finished an 'alpha' version of the SVG demo program that complies with the new websocket protocol (RFC6455). Below is a rough list of release notes, along with a 'to do' list that I will be working on in the coming weeks.

Changes:

1. Changed the handshake and websocket read/write VI's to conform to the RFC6455 version of the websocket protocol currently supported by Chrome 16.

2. Replaced the string indicator on the main front panel with a dialog that pops up when a message is received from the client (from clicking the buttons and switch on the SVG document.

3. Tested the demo with Chrome version 16.0.912.75 m. Seems to work OK so far. If you find bugs, let me know. I did not test the script and program with any other browser. I use Chrome exclusively, with the intention of using this system with Android tablets and Chrome OS. I do not currently own a tablet, so if anyone tests it, please

4. Cleaned up the folder system for the project and got rid of the RGraph library demo, as well as a bunch of other files that were not used and cluttering up the folders. I will no longer be working with the RGraph library, and will instead focus on the webpanel library.

As with the previous version, open the WebPanel project and the SVGDemo VI. Run the VI, then open the \www\WebPanelTest.svg file on the same computer. It should connect to the listener and begin updating.

Disclaimer:
Please test and use the library however you wish. No warranty is implied, and I am not responsible for anything that happens as a result of using this code. Downloading the file acknowledges this disclaimer.


 WPLavaG.zip   529.8K   141 downloads

LabVIEW 2009 or later is required. Please contact me for earlier versions (will need 8.5 min due to the use of classes).


My to do list (not necessarily in the order presented here)

1. Change my web host to a suitable provider and migrate the files to a subversion directory.
2. Rework the websocket Labview Class and add dynamic dispatching to accomodate future revisions of the websocket protocol
3. Change the SVG namespace of the webpanel objects to shorten the name.
4. Clean up and document the ecmascript file and look at new methods of controlling the objects.
5. Document the SVG elements and create new objects.
6. Fully document everything in a PDF file, with commentary on methodology
7. Create new website with documentation and file download area.
8. Offer the package to OpenG.org
9. Change the protocol to binary
10. Migrate the ecmascript engine to open source.

Please post your comments/questions on this version here, or message me privately if you wish. Thanks, everyone, and happy SVG'ing.

I should also note the LabVIEW side of the demo does not cleanly close the websocket on shutdown, as I have not yet added any control frames to the new protocol. Also,in case you missed it, while the new protocol supports binary, I opted for text so I wouldn't have to make any changes to the javascript. Obviously, binary is a better choice, but that is down the road because it will require the data parsing portion of the script to be overhauled. I also want to spend some time thinking about what the binary protocol should look like. Any thoughts on this subject are welcome. I hope to have the new website up and running sometime before the end of Feb.

[ShaunR]

I noticed that you had this in your JS

top.wpSend = wpSend; //for sending webpanel msg from HTML if SVG is embedded. Firefox 4 only (no Chrome)

I'm guessing this comment is because you get a x-server script error when using chrome to access a "file://" URI (i.e a local file rather than an "http://" URI). You can override this limitation by launching chrome with the command-line switch "-allow-file-access-from-files". You should then be able to connect after opening an html file on the local file system without an error.

[jgcode]

...because you get a x-server script error when using chrome to access a "file://" URI (i.e a local file rather than an "http://" URI). You can override this limitation by launching chrome with the command-line switch "-allow-file-access-from-files". You should then be able to connect after opening an html file on the local file system without an error.

Using a web-server in the past has fixed my XSS issues (among other things).
I am interested to try out the switch you have posted i.e. does it allow cookies to work in chrome?

[ShaunR]

Using a web-server in the past has fixed my XSS issues (among other things).
I am interested to try out the switch you have posted i.e. does it allow cookies to work in chrome?

No-eyed-deer. This is purely a mismatch in the URI which chrome resricts by default (firefox, Safari and explorer don't exhibit this behaviour). I have only had this problem with websockets since I have never had the need to send cookies from labview. So I guess if your cookie issue works in the other browsers but not in chrome, then maybe it will solve it- you tell me

[smarlow]

I noticed that you had this in your JS

I'm guessing this comment is because you get a x-server script error when using chrome to access a "file://" URI (i.e a local file rather than an "http://" URI). You can override this limitation by launching chrome with the command-line switch "-allow-file-access-from-files". You should then be able to connect after opening an html file on the local file system without an error.

Thanks for the tip. I had put that function in for use with HTML form buttons when the user was embedding the script in an HTML file. I could never get the function to work with Chrome, but it worked with Firefox. I'll try it again with your suggestion. Like I said, I really need to clean up the script, as I have a bunch of notes to myself in there, and some code that was used merely for debugging. I plan to revise it and release it again on the new website. Thanks for your help.