You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 29, 2021. It is now read-only.
This is very much work in progress, and needs further testing/debugging. I am marking this as a bug until the tests show that it is working. I reckon that it is pretty close to working, but I ran out of time today. The work involves changing the example of calling wot.proxy in demo.js to point to the second server.
The text was updated successfully, but these errors were encountered:
One piece of work that I have still to code up is handling queuing of messages that are received for a thing that has yet to start. Further work is also needed on error handling, including timeouts for resolving dependencies.
This has two cases: a) registering a proxy on this server for a thing on another server and b) registering a proxy on another server for a thing on this server. This latter case is needed to expose a thing hidden behind a firewall+NAT boundary, for instance when an IoT device in a smart home wants to expose itself via a proxy hosted by a cloud based server.
Some progress in bug fixes! But at the same time I am rethink how I deal with host names.
The scripting API wot.register_proxy(uri, callback) can be used for a remote thing, but it would be desirable for it to also work for local things declared with wot.thing(). However, that isn’t essential. I need to check, but right now, believe that my code works for local things even if they haven’t yet been declared. It checks that the URI provided is for this machine. A simple and less robust approach would be to require an absolute server path without the host name, and/or to require the use of “localhost” in the URL.
For remote things, the URI will typically be for an external hostname. When a target server gets a proxy registration request via web sockets, it should assume that it is for a local thing and ignore the hostname used for the connection.
The client server should re-use the same connection for all things on the same target server. This is possible by comparing the host name for those things.
We would like to avoid having to have two web socket connections when server A proxies a thing on server B, which in turn proxies a thing on server A. For this we need a way to verify that an existing connection on server A is for server B, even though it was opened by server B as a connection to server A. One potential solution is for server B to send a message when it opens the connection: {host: os.hostname()}
I will commit the new code soon.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
This is very much work in progress, and needs further testing/debugging. I am marking this as a bug until the tests show that it is working. I reckon that it is pretty close to working, but I ran out of time today. The work involves changing the example of calling wot.proxy in demo.js to point to the second server.
The text was updated successfully, but these errors were encountered: