Revert to Previous Peer De-registration Behavior
The quandry is what to do with peers that have disappeared for too long. If we keep trying to re-register, we could be quite busy doing that for an eternity… but if we de-reg the peer and it comes back in 10 minutes, but, say, never lost the master, we don’t get a peer list for a LONG time and we don’t get it back then either…. There’s no good answer right now. Anyone got one?
This commit is contained in:
parent
98b12aedd3
commit
f3e2d53d9f
@ -105,7 +105,7 @@ try:
|
||||
'PEER_OPER': True,
|
||||
'PEER_MODE': 'DIGITAL',
|
||||
'FLAGS': '',
|
||||
'MAX_MISSED': 10,
|
||||
'MAX_MISSED': 20,
|
||||
'NUM_PEERS': 0,
|
||||
'STATUS': {
|
||||
'ACTIVE': False
|
||||
@ -312,9 +312,8 @@ def process_peer_list(_data, _network):
|
||||
# This is done elsewhere for the master too, so we use a separate function
|
||||
_decoded_mode = process_mode_byte(_hex_mode)
|
||||
|
||||
# Write or re-write this peer if it's already in our list. Why re-write? Mode may have changed!
|
||||
# This means we'll re-register with a peer who we may have already been registered with, but
|
||||
# that doesn't appear to hurt anything.
|
||||
# If this entry was NOT already in our list, add it.
|
||||
if _hex_radio_id not in NETWORK[_network]['PEERS'].keys():
|
||||
NETWORK[_network]['PEERS'][_hex_radio_id] = {
|
||||
'IP': _ip_address,
|
||||
'PORT': _port,
|
||||
@ -638,7 +637,7 @@ class IPSC(DatagramProtocol):
|
||||
# If we have missed too many keep-alives, de-register the peer and start over.
|
||||
if peer['STATUS']['KEEP_ALIVES_OUTSTANDING'] >= self._local['MAX_MISSED']:
|
||||
peer['STATUS']['CONNECTED'] = False
|
||||
peer['STATUS']['KEEP_ALIVES_OUTSTANDING'] = 0
|
||||
del peer # Becuase once it's out of the dictionary, you can't use it for anything else.
|
||||
logger.warning('(%s) Maximum Peer Keep-Alives Missed -- De-registering the Peer: %s', self._network, int_id(peer_id))
|
||||
|
||||
# Update our stats before moving on...
|
||||
|
Loading…
Reference in New Issue
Block a user