Recent changes to bugs

Peer can't rejoin if he has been disconnected

Stefan Kraxberger — Mon, 01 Dec 2008 08:44:06 -0000

If a peer has been disconnected or has left the network without sending the LeaveNetworkInfo than it isn't possible for the same peer to rejoin again because he finds itself as part of the network as he tries to join himself.

Problem with finding route after a peer has rejoined

Stefan Kraxberger — Wed, 26 Nov 2008 21:47:44 -0000

After a peer has rejoined the network there exists a problem in the route discovery (maybe even in the connections) with peers behind the rejoined peer.

Member list isn't updated at neighbors of rejoining peers

Stefan Kraxberger — Wed, 26 Nov 2008 21:44:04 -0000

If a peer has been joined previously and disconnects than after joining again there exists a problem at the neighbors because their member list isn't updated correctly, only at the one neighbor (or that part of the network) with which he joins again.

Remove neighbors from member list

Stefan Kraxberger — Thu, 20 Nov 2008 10:34:49 -0000

Remove neighbors from members list if they are not reachable anymore and send a NetworkInfo message to inform all the other members about the disappearance of this peer.

Problem with NetworkRequest

Stefan Kraxberger — Tue, 18 Nov 2008 10:05:52 -0000

After the startup there is a problem with forwarding the NetworkRequest messages. Because the starting peers send these messages to their neighbors. The neighbors should only reply to them. But if for instance a neighbor isn't available the messages are forwarded to the other neighbors and they want to find a route which should not happen since only the 1-hop neighbors should respond. Problem in the STM receive message method or in the storing of the messages.

Problem with segmentation

Stefan Kraxberger — Wed, 05 Nov 2008 12:52:23 -0000

A problem has been reported about the segmentation algorithm in the version used for SMEPP.

Removing members depending on proxy peer removal

Stefan Kraxberger — Fri, 31 Oct 2008 14:22:02 -0000

We could also think about removing the peers from the member list if the peers over which we route messages to others left the network.

This means that all the peers which are after a peer which currently left the network should also be removed from the member list after one attempt of discovering a new route to them.

Finding neighbors not sufficient

Stefan Kraxberger — Fri, 31 Oct 2008 14:13:48 -0000

We are currently use the NeighborRequest to keep the connections with known neighbors alive or create them. We don't discover any new peers through this mechanism.

We only add a neighbor if we have a direct connection with them which. This is the case if one peer has another peer specified as neighbor in the configuration but the other one not.

We should find a way to obtain new neighbors depending on the network topology and size.

Member list is not updated

Stefan Kraxberger — Fri, 31 Oct 2008 14:10:55 -0000

If a peer receives message from peers which he hasn't on his member list the member list is not updated. Therefore, the peer can't send messages to them, only receive messages.

We should also remove peers from the member list if they are not reachable. This means that if a certain amount of connection attempts fail we should remove them from the member list.