OC P2P odness #2087
OC P2P odness #2087
Comments
Looks like the tunnel is never handling being disabled/removed and updating the OC connection accordingly. They simply create a connection and go to sleep forever. I do not really know the OC API, so @fnuecke should really look into it. |
Yeah, I'll have a look. To clarify, the connection gets established via the tunnel, but when the tunnel goes offline, the OC subnets on either side of the tunnel stay connected? |
You might also want to look into But I cannot really test it as I have no idea how to even use the most basic OC stuff. |
@fnuecke What I did was that I connected 21 OC P2P tunnel to my network, then I saved the settings from one P2P and loaded them into the other 20 P2P tunnels. Then I connected all peripherals and the computer and started my program. As I wanted to change a variable and closing the program over touch doesn't work at the moment, I wanted to crash the OC computer with "no such component" by disconnecting the me cable from the P2P tunnel. The P2P tunnel went offline but the computer did still update the information from the peripherals. |
@yueh onTunnelNetworkChange is overridden in PartP2POpenComputers.java and contains code to wake the P2P up but onConnect and onDisconnect are overridden and are empty. |
From what I can remember, the The |
Ah, ok, didn't know they were from OC. |
Neither of these methods are overridden in PartP2POpenComputers.java |
…t port validity, closes AppliedEnergistics#2087. Instead of just `onTunnelNetworkChange`, this way it is more stable and more exhaustive, avoiding issues with network splits and reconnects not being handled in some cases. Also added check for output port validity when connecting from the perspective of the input, which may potentially have led to invalid connections.
…t port validity, closes AppliedEnergistics#2087. Instead of just `onTunnelNetworkChange`, this way it is more stable and more exhaustive, avoiding issues with network splits and reconnects not being handled in some cases. Also added check for output port validity when connecting from the perspective of the input, which may potentially have led to invalid connections.
…on, fixes AppliedEnergistics#2087. Just `onTunnelNetworkChange` with tickable is apparently less exhaustive, and less stable. This now avoiding issues with network splits and reconnects not being handled in some cases. Also simplified reconnection; there was some duplicate logic in there, with a missing validity check which potentially led to invalid connections.
…on, fixes AppliedEnergistics#2087. Just `onTunnelNetworkChange` with tickable is apparently less exhaustive, and less stable. This now avoids issues with network splits and reconnects not being handled in some cases. Also simplified reconnection; there was some duplicate logic in there, with a missing validity check which potentially led to invalid connections.
See #2088. |
…on, fixes #2087. Just `onTunnelNetworkChange` with tickable is apparently less exhaustive, and less stable. This now avoids issues with network splits and reconnects not being handled in some cases. Also simplified reconnection; there was some duplicate logic in there, with a missing validity check which potentially led to invalid connections.
If I try to crash my OC computer with a "no such component" error by disconnecting the me cable in the back of the P2P, the P2P goes offline but the OC network is not disconnected and the OC computer still gets updated data. Any ideas @fnuecke?
AE: rv3 beta 2
OC: 1.5.20
The text was updated successfully, but these errors were encountered: