Connection to websocket not working anymore

[Flydroid]

Hi Derrick,

I was starting to build a webapp for plotly graphs on top of your websockets example. Learning javascript and websockts was a nice challange over the holidays with to goal to get nice interactive graphs in Labview. And it did work well for for a while until it stopped working as the websocket connection could not be opened anymore. I tried on a different computer, with a fresh install of the messaging example from vipm and its depencies, same case.

I then used rawcap and wireshark to get logs from localhost while opening the webpage. port 4663

port 7080:

Both the the http port and websocket port seem to have a bunch of bad packets. Unfortunatly I dont know enough low low level network communication to further analyse the problem

The LV client with the TCP communciation worked fine, as expected:

Hopefully with the pcap file you can see more on what is going on: lv_msg_combo_example.zip

[negentropicdev]

Heya @Flydroid I'm taking a look. This is just the tcp/websocket combo example, right?

[negentropicdev]

For some reason the connection is immediately being closed without any returned data when the browser is sending the websocket connection request. (I've removed the unrelated packets from the screenshot) Unfortunately I haven't come up with a comprehensive error propagation scheme for this code path (sorry I got lazy, I didn't have issues here heh)

Can you open the Websocket Client.lvclass:Handshake.vi from the dependencies and see the error out value?

It's non-reentrant so you should just be able to open it and check it once you trying opening the websocket connection from the webpage.

[Flydroid]

Hi Derrick,

Thanks for checking the issue so quickly. Your lead was good and it got me to the Stream-Websocket-lvlib:Check is Upgrade Request.vi:

And it was a decimal-point bug. Setting the "use system decimal point" on the "Frac/Exp String to Number" function to FALSE, fixes the bug. Now i also know what it did work for me at first, because i was working on a computer with a different region setting, but later the region setting.

[negentropicdev]

Thanks for digging into that. I should be able to get the packages updated later today.

[Flydroid]

Great! Thank you!

I had another question for you ( which wanted to send on linkedIn originally) but maybe it fits just here to: How does the simpler approach use in this example compare to your full http server? I think for my project this is enough (i added a little bit of code to serve the html and javascript files upon request), but I wonder if its better to base of the full http server?

[negentropicdev]

One of the main nice things of using the combined server is a single port for both webpage serving and websocket connections. As well as the capability of having different websocket servers accessible on that single port identified by different URLs. It also makes it trivial to serve both WSS and HTTPS (TLS).

And then of course it has easy file serving so that you can leave the webpage content and JS content as separate files on disk which are easier to manage, without having to write your own file serving code and it already does checks for things like trying to ascend out of folders and using invalid path elements ('.' and '..').

Plus if you ever decide you want more capabilities and get up to speed on developing handlers and controllers for the http server you have that available for the future.

[negentropicdev]

@Flydroid IG WebSocket Stream has been updated and no longer uses the system localized separator. If you refresh your packages in VIPM you can update it and be ready to go again

[Flydroid]

One of the main nice things of using the combined server is a single port for both webpage serving and websocket connections. As well as the capability of having different websocket servers accessible on that single port identified by different URLs. It also makes it trivial to serve both WSS and HTTPS (TLS).

And then of course it has easy file serving so that you can leave the webpage content and JS content as separate files on disk which are easier to manage, without having to write your own file serving code and it already does checks for things like trying to ascend out of folders and using invalid path elements ('.' and '..').

Plus if you ever decide you want more capabilities and get up to speed on developing handlers and controllers for the http server you have that available for the future.

That sounds pretty good. I need to have another look at the examples and your gla summit presentation to learn how it works, the controllers and handlers, but also the page loading had some complexity to them.

[negentropicdev]

Give me a couple of days and I'll make some more focused videos on the basics. They're not that bad, I was just trying to cover too much on the presentation heh.