Understanding Kraken tracker announce request & setting egress/ingress bits
callmeyesh opened this issue · comments
We are using spot instances on AWS as Kraken agents. Which means AWS can kill these instances anytime. I am seeing some Error initializing outgoing handshake in the kraken-agent logs
2020-11-13T21:18:42.811Z INFO scheduler/scheduler.go:407 Error initializing outgoing handshake: dial: dial tcp 10.162.97.195:16001: i/o timeout {"peer": "e69aaeb9f8626796d049c7b6cf21275fac80fdfc", "hash": "34311dd60b630c728d0e188dc0b7e11cd311b3d2", "addr": "10.162.97.195:16001"}
2020-11-13T21:18:42.811Z INFO scheduler/scheduler.go:407 Error initializing outgoing handshake: dial: dial tcp 10.165.213.5:16001: i/o timeout {"peer": "84eb169b49456cf0e1540ba456ebb63fb68425a8", "hash": "34311dd60b630c728d0e188dc0b7e11cd311b3d2", "addr": "10.165.213.5:16001"}
2020-11-13T21:18:42.811Z INFO connstate/state.go:210 Deleted pending conn, capacity now at 9 {"hash": "34311dd60b630c728d0e188dc0b7e11cd311b3d2", "peer": "e69aaeb9f8626796d049c7b6cf21275fac80fdfc"}
2020-11-13T21:18:42.811Z INFO connstate/state.go:157 Connection blacklisted for 30s {"peer": "e69aaeb9f8626796d049c7b6cf21275fac80fdfc", "hash": "34311dd60b630c728d0e188dc0b7e11cd311b3d2"}
2020-11-13T21:18:42.811Z INFO connstate/state.go:210 Deleted pending conn, capacity now at 10 {"hash": "34311dd60b630c728d0e188dc0b7e11cd311b3d2", "peer": "84eb169b49456cf0e1540ba456ebb63fb68425a8"}
2020-11-13T21:18:42.811Z INFO connstate/state.go:157 Connection blacklisted for 30s {"peer": "84eb169b49456cf0e1540ba456ebb63fb68425a8", "hash": "34311dd60b630c728d0e188dc0b7e11cd311b3d2"}
2020-11-13T21:18:42.918Z INFO scheduler/scheduler.go:407 Error initializing outgoing handshake: dial: dial tcp 10.162.97.195:16001: i/o timeout {"peer": "e69aaeb9f8626796d049c7b6cf21275fac80fdfc", "hash": "4510c63237a54606f195bcbb9401ca7b0c25219d", "addr": "10.162.97.195:16001"}
2020-11-13T21:18:42.918Z INFO connstate/state.go:210 Deleted pending conn, capacity now at 9 {"hash": "4510c63237a54606f195bcbb9401ca7b0c25219d", "peer": "e69aaeb9f8626796d049c7b6cf21275fac80fdfc"}
I suspect this is because I have peer_set_window_size: 1m & max_peer_set_windows: 5, which means the announce requests are only expiring every 5mins but the agents are getting preempted? Is my understanding correct?
I want to understand what the announce request means? Is it the time frame a tracker will keep the IP of the peer and share it with other peers?
Also is there a default egress & ingress limits for agents & origins? We are using peers which have 10 Gigabit network performance & 25 Gigabit on the origins. I wasn't sure if these limits are applied by default on all agents and origin.
I suspect this is because I have peer_set_window_size: 1m & max_peer_set_windows: 5, which means the announce requests are only expiring every 5mins but the agents are getting preempted?
This seems reasonable. Your peers are still discoverable for up to 5 minutes after they are preempted, during which new connections to them will time out since the host is offline. There's not really a good solution here other than to simply let the invalid peer data expire (since hopefully preemption is infrequent).
I want to understand what the announce request means? Is it the time frame a tracker will keep the IP of the peer and share it with other peers?
An announce request is a peer announcing that it has a particular torrent to the tracker. The tracker independently decides how long to cache said peer's announce information (ip+port+torrent).
Also is there a default egress & ingress limits for agents & origins? We are using peers which have 10 Gigabit network performance & 25 Gigabit on the origins. I wasn't sure if these limits are applied by default on all agents and origin.
These are indeed the defaults applied to both agent & origin, which share the same torrent libraries.