Open TechWizEric opened 9 years ago
this issue will be on every platform theoretically.
when the Workbench starts it binds to a UDP listener port on the current IP address. if you change/renew your network or DHCP license and get a different IP address you would need to restart the workbench to bind to the newly associated IP address.
there should be someway of detecting via a notification (possibly in node.js) that the network connection has been lost/changed and respectively re-bind to the UDP port on the computer so it is discoverable - are we attaching a callback to the dgram.createSocket function call? there may be an event broadcast when the network changes which we could monitor and react based on this.
This is likely an issue in HyperReload, not evothings-studio.
It would be useful to check with Wireshark what UDP packets are received by the computer.
The UDP listener does rebind to the new IP. Note that I wrote "The workbench server cannot be found by the client app, even after restarting the workbench.".
I will investigate and check with e.g. Wireshark that the UDP packets from the client are received by the computer.
ok, so we have a separate issue to create for avoid restarting the workbench.
No I think it already rebinds to avoid having to restart the workbench. Anyway there should otherwise already be an issue for that, I remember writing it!
Separate issue: https://github.com/evothings/evothings-studio/issues/17
The issue is suspected to occur after the system has been in Hibernation mode, and may occur even when the WiFi network didn't change.
Tried to reproduce the issue by forcing OS X to go into Hibernation mode, but failed. Also simulated switching WiFi networks while in Hibernation. Will try reproducing it by letting the system go to Hibernation mode the normal way, e.g. leaving the computer in sleep mode while on battery power during a night's time.
The Workbench computer doesn't receive the broadcast packets from the client, evident by looking at the traffic captured by CocoaPacketAnalyzer. This issue is therefore considered to belong to OS X internals and cannot likely be corrected in ETC or ETS other than through workarounds. I will keep this issue open to raise awareness.
After I move my OS X (10.10) laptop from one to another known Wi-Fi network, the workbench cannot be found. The usage scenario is this: