Different platforms, different results

[mrgasparov]

Hi, and thanks for this amazing addon!

I'm writing an app for the RPi/RPi2 using ofxLibwebsockets and have been building and running succesfully, and accessing the html on port 9092 from within the pi's browser and from remote clients in my network.

However I've been facing some issues when trying to load the html on remote clients and achieving a consistent websocket connection. There were situations where the websocket doesn't connect at all and the browser isn't detected, and others where it would connect about 60% of times as I would refresh the page.

To try to figure out what was going on I've compiled and run example_server_sharedcanvas in 3 different platforms and achieved very different results in terms of socket connection reliability.

I'll try to sum it up:

-> When running on MacBook Pro + OS X 10.10.3

-- socket connects 100% ---- over wifi - iphone ---- over lan - win 7, ubuntu vm

-> When running on Ubuntu 14.04.1 VM

-- socket connects 100% ---- over lan - win 7, os x, rpi2

-- socket doesn't connect ---- over wifi - iphone ---- over lan - rpi2

-> When running on RPi2 w/ Raspbian Wheezy

-- socket connects 100% ---- over lan - win 7

-- socket doesn't connect ---- over wifi - iphone ---- over lan - os x, ubuntu

Since the OS X version works with all client platforms and browsers and my mac is quite new, this seems like a performance issue on the server side. Could also be caused by some bug on the libwebsocket builds on the linux platforms.

Is there any solution on the JS side? (I'm a JS dummy) Or is there anything else you can think of that might be causing these discrepancies?

Thanks!! Pedro.

[robotconscience]

Hm! Thanks for such a detailed issue repot.

On Jun 26, 2015, at 3:56 PM, Pedro Mendes notifications@github.com wrote:

Hi, and thanks for this amazing addon!

I'm writing an app for the RPi/RPi2 using ofxLibwebsockets and have been building and running succesfully, and accessing the html on port 9092 from within the pi's browser and from remote clients in my network.

However I've been facing some issues when trying to load the html on remote clients and achieving a consistent websocket connection. There were situations where the websocket doesn't connect at all and the browser isn't detected, and others where it would connect about 60% of times as I would refresh the page.

To try to figure out what was going on I've compiled and run example_server_sharedcanvas in 3 different platforms and achieved very different results in terms of socket connection reliability.

I'll try to sum it up:

-> When running on MacBook Pro + OS X 10.10.3

-- socket connects 100% ---- over wifi - iphone ---- over lan - win 7, ubuntu vm

-> When running on Ubuntu 14.04.1 VM

-- socket connects 100% ---- over lan - win 7, os x, rpi2

-- socket doesn't connect ---- over wifi - iphone ---- over lan - rpi2

-> When running on RPi2 w/ Raspbian Wheezy

-- socket connects 100% ---- over lan - win 7

-- socket doesn't connect ---- over wifi - iphone ---- over lan - os x, ubuntu

Since the OS X version works with all client platforms and browsers and my mac is quite new, this seems like a performance issue on the server side. Could also be caused by some bug on the libwebsocket builds on the linux platforms.

Is there any solution on the JS side? (I'm a JS dummy) Or is there anything else you can think of that might be causing these discrepancies?

Thanks!! Pedro.

— Reply to this email directly or view it on GitHub.

[robotconscience]

Ha, sorry, email sent early.

My primary platform is Mac, so sadly I can't debug as well as you! I'd recommend a few things:

1 - check out the issues list on libwebsockets (under github.com/warmcat I believe) and make sure there's not any outstanding issues on those platforms. I may have to recompile the lib if so, but good to know if there's a fix

2 - try a simple socket in JavaScript, and use the websocket "onerror" method to catch any errors its getting. If it's getting an error connecting at all, it could be more of a network issue.

Lastly, I'll check and see if there are any overrideable timeouts in the library. Perhaps it's just taking longer to handshake, and timing out over wifi. Will keep you posted!

If you're extra ambitious, you can try compiling libwebsockets on your platform in DEBUG mode. Once you swap the library in, you'll get a ton more info on what's happening under the hood of libwebsockets!

[mrgasparov]

Hi,

Thanks for such a quick reply! Here are my answers:

1 - I scanned quickly through the lws repo issue list and didn't find anything relevant really. The only real issues seem to come when trying to connect through SSL. Anyway I'll have a more detailed read through later today.

2 - Wil try this. Would it be possible to try a reconnect automatically "onerror"? I have tried replacing WebSocket with ReconnectingWebSocket (https://github.com/joewalnes/reconnecting-websocket), but didn't have much success... If you have any ideas, a code snippet would be much appreciated ;)

I will also try the lws debug compile and will let you know of relevant messages I get.

[robotconscience]

All sounds good! The reconnecting library looks good, but I think we need more info from the onError message. Checkout this snippet from WebSocket.org: https://www.websocket.org/echo.html

Just edit the var wsUri = "ws://echo.websocket.org/"; to the IP of your machine, and you're all good!

Keep me posted here, sorry it's such a rabbit hole!

[mrgasparov]

Using the websocket echo example HTML you suggested I managed to connect and retrieve 1st JSON line 100% of times from all clients (including iphone over WiFi!), when connecting to "example_server_sharedcanvas" running on the RPi2!

Same is true for "example_server_sharedcanvas" running on OS X and Ubuntu on VM, however the connection to the Ubuntu server took around 10s from an external client (this suggests that that example html is capable of waiting for socket connection sucsess for that long!)but that might be due to weird VM internal networking.

Also tried having the html hosted on a local http server, pointing to the RPi2 server, and got excellent results on all platforms.

And finally with the html placed inside bin/data/web on the RPi2, pointing to itself, and got excellent results on all platforms.

So.... This is great news as it seems like the issue is actually within "main.js" and how it is handling connections OR that the files on bin/data/web aren't being sent to the browser entirely/correctly in some cases.

I'd love to give you a hand here, and will try my best, but it'll be slow ;)

[robotconscience]

That's awesome! I'll try to tackle it this week some time. Those javascript/html files need clean up for sure regardless.

Thanks so much for investigating all this! Will keep this issue open until the files are all cleaned up.

[mrgasparov]

OK meanwhile... I did a messy merge between the HTML example from the websockets website and your main.js and got it to work! It seems the issue is with the canvas initialisation, because i managed to get it working by commenting out this section:

canvas      = document.getElementById("sketchCanvas");
canvas.onmousedown  = onMouseDown;
canvas.onmouseup    = onMouseUp;
canvas.onmousemove  = onMouseMoved;
ctx         = canvas.getContext('2d');

So I think that's pretty much problem solved for me... When you have the time please investigate it and let me know of the outcome!

Cheers, Pedro.

[robotconscience]

Quick question: are you still using the "get_appropriate_ws_url()" function? Trying to see if there's any issue with that as well.

Can you post the code that's working for you? Looking into this now!

[mrgasparov]

Sorry for the silence but I've been busy with a load of other stuff :( I'll get back to you this weekend with the code I tested successfully.