simulator icon indicating copy to clipboard operation
simulator copied to clipboard

Peer added to the graph again even after removing from the team

Open sachinsngh165 opened this issue 6 years ago • 12 comments

Even after removing from the team, some peers are adding again in the graph while plotting. Console shows that peer have been removed from the graph but it doesn't.

sachinsngh165 avatar Jul 05 '18 12:07 sachinsngh165

@cristobalmedinalopez A quick solution would be to put NODE OUT line in drawing file whenever a peer receives good bye message from the splitter. Also, respond to request message if and only if the sender is in peer list.

sachinsngh165 avatar Jul 05 '18 12:07 sachinsngh165

@cristobalmedinalopez, is there any scenario when above solution would fail?

sachinsngh165 avatar Jul 26 '18 08:07 sachinsngh165

What should we do for following scenario: When peer receives a request messaege from removed peer before receiving good bye message from the splitter. if we follow this solution:

@cristobalmedinalopez A quick solution would be to put NODE OUT line in drawing file whenever a peer receives good bye message from the splitter. Also, respond to request message if and only if the sender is in peer list.

then removed peer would appear for time until it don't receives a good bye message.

sachinsngh165 avatar Jul 26 '18 08:07 sachinsngh165

A quick solution would be to put NODE OUT line in drawing file whenever a peer receives good bye message from the splitter.

You mean it removes itself, isn't it?

Also, respond to request message if and only if the sender is in peer list.

Yes, it sounds good!

When peer receives a request messaege from removed peer before receiving good bye message from the splitter (edited).

Does that action trigger the writing of a NODE IN line in the drawing file?

cristobalmedinalopez avatar Jul 26 '18 09:07 cristobalmedinalopez

Does that action trigger the writing of a NODE IN line in the drawing file?

yes, whenever a peer receives a request message from another peer, and if it is not in the forwarding list of origin (of requested chunk), then it write NODE IN for sender in drawing file, that's the cause of this bug. This would overwrite splitter's action of NODE OUT.

sachinsngh165 avatar Jul 26 '18 09:07 sachinsngh165

A quick solution would be to put NODE OUT line in drawing file whenever a peer receives good bye message from the splitter.

You mean it removes itself, isn't it?

No, i was talking in reference to other peers who will receive GOODBYE message from removed peers.

sachinsngh165 avatar Jul 26 '18 09:07 sachinsngh165

No, i was talking in reference to other peers who will receive GOODBYE message from removed peers.

It could work with honest peers.

cristobalmedinalopez avatar Jul 26 '18 09:07 cristobalmedinalopez

Even if every peer put NODE OUT on receiving GOODBYE message, even then removed peer may appear in network overlay for a tiny interval of time (like a ghost). Because a peer may receive request message before goodbye message. Do you @cristobalmedinalopez think we can do something with that, because possibility seems very low ?

sachinsngh165 avatar Jul 27 '18 08:07 sachinsngh165

Even checking sender in peer_list before responding to request_chunk message will not work due to above reason.

sachinsngh165 avatar Jul 27 '18 08:07 sachinsngh165

I think it's not an important issue that removed peers appear like a ghost if finally they are completely removed from the graph. What do you think @vicente-gonzalez-ruiz? Any other idea @josmanual?

cristobalmedinalopez avatar Jul 27 '18 08:07 cristobalmedinalopez

@cristobalmedinalopez , how should we check if removed peer is in peer_list or not, as we just have a forwarding list? should we check this peer in every forwarding list ?

sachinsngh165 avatar Aug 01 '18 15:08 sachinsngh165

No, I think it would be enough checking the forwarding list of itself (where it is the origin).

cristobalmedinalopez avatar Aug 02 '18 09:08 cristobalmedinalopez