suppression of communication errors

[sdellutri]

I am using the netremote with Girder and have been very happy with the way things are working. When starting up the system, I sometimes run into situations where the PDA will be running and the HTPC will be powered off. For this situation I am taking advantage of the WakeOnLan features to start the system. (and it works great too!)

The problem is that if I accidentally push another button on the netremote, it will attempt to send that command to girder. For the time period between attempting to start the PC and girder being online, the netremote throws error messages that it cannot connect. You can attempt to dismiss them, but eventually, it locks up the PDA and I have to push the hard reset button.

Can you suppress these error messages, and simply retry in the background? Maybe there is a better way to show the error condition to the user? Maybe you could change the color of the skin header from blue to red when this happens, and then change it back to blue when the communication link has been established?

On a somewhat related topic, I have seen posts to this forum where users were discussing their startup times. I wonder if there were some way for Netremote and Girder to use the UDP protocol instead of TCP. This could potentially reduce the startup time, and mask the whole error condition issue that I described above. It could also be useful where girder could send status update messages (maybe broadcast) to all netremote clients and they wouldnt have to have been registered or not.

Just some ideas to improve the experience...

I think you are doing a great job and I really love the netremote.
Thanks,
SD

[Ben S]

Done. Error messages suppressed. I am working on a shared logging system for all of NetRemote (including the drivers), but for now I have just hid the error messages. I have gotten hit by this one a few times, myself.

In regards to UDP, I think that is something I'm going to look into, someone else had asked about that before, as well.

[sdellutri]

Thanks!
Cant wait to see your latest updates!

[brockgr]

Ben, yep - I asked for UDP messaging. And I just realised big time why we need it.

I'm currently working on a Zoomplayer panel, with udates of track time etc. While I was playing a movie, I turned off NetRemote. When I turned it back on, it spent 10 minutes recieving updates that had backlogged in Girder.

We could have a time out on the TCP connection, but since Girder is single threaded, it still blocks unacceptably (I can't change volume while my DVD player is timing out :shock:). For this reason, a fire and forget message type would be great.

To keep things simple to start with, shall we ignore broadcast/multicast and just send a unicast UDP packet to the registered feedback ip/port. I don't see any reason to even use a different message payload either.

I should be able to add that fairly easily on the LUA side.

Any thoughts?

Gavin

[brockgr]

Ok I put a UDP sender in the lastest LDJ build here (http://www.netremote.org/phpBB2/viewtopic.php?p=470#470).

You can see an example in the "LUA Feedback", "Examples", "one low priority value".

The function is called "NR_send_udp_label_feedback" for now.

Gavin

[sdellutri]

I was thinking about the network communication some more. I wonder if instead of letting the net remote client register to girder and then girder initiating sessions back to the netremote, if it would work better if the feedback just went back over the existing established tcp session to netremote.

Netremote could establish the session on startup and keep this connection open to get feedback, or it could close it and immediately re-establish connections.

This would eliminate the whole registering step, and may make it easier to connect to the system when having to traverse firewalls, nats, and proxy servers on the internet.

[brockgr]

Yep that could work. Ben any views? It might improve performance. We would have to be carefull about not messing up the protocol though - the current open/close system does allow us to tidy up.

Gavin

[Ben S]

I think this would only work if we coded the listening into the luasocket code as well. Right now I'm talking to the Internet Event Server, so I don't believe we can share the same connection without changing the way we're sending events.

The only downside is that we lose the ability to "share" gml usage among HouseBot, Mainlobby, and other similar apps.

I'll continue more in your protocol thread.