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

[sachinsngh165]

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

[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]

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

[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.

[cristobalmedinalopez]

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?

[sachinsngh165]

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]

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.

[cristobalmedinalopez]

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

It could work with honest peers.

[sachinsngh165]

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]

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

[cristobalmedinalopez]

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?

[sachinsngh165]

@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 ?

[cristobalmedinalopez]

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