Questions on Freenet - Second Try

Hello

Unfortunately, my previously transmitted questions have not been =20
answered so far. Maybe the large amount of questions was daunting. I =20
have reduced it to a few questions which can be answered, hopefully, =20
in a straightforward fashion.

Path Folding and Connection Managment:

- Is it required that the data source actually starts to send a "path =20
folding" offer back along the path or might any node on the path =20
simply decide to send its node reference back along the path, hoping =20
to get new connections?

- Does the data source always send the "path folding" offer back or is =20
it possible to omit this. If the latter is the case, does this imply =20
that there is no chance for creating new connections on this =20
particular path?

- If one node answers the "path folding" offer and a new connection is =20
created, is this "path folding" offer then passed back further along =20
the path or does it stop at that node?

- When connecting to a new node, how is the Friend-of-a-Friend =20
information (i.e. the locations of the node's neighbors) exchanged?

- Churn leads to frequent changes in the neighborhood of a node. How =20
is the Friend-of-a-Friend information maintained to keep the =20
maintenance overhead small?

Freenet's Load Balancing:

- Relaying a request requires to keep track of it, i.e. the node needs =20
to store information to be able to return the corresponding response =20
at a later time. Due to resource limitations, a node cannot accept =20
arbitrary requests and maintain state for them.

-> So, requests can actually decide to reject a request depending on =20
their current load. The corresponding connection is marked as "backed =20
off", i.e. an exponential growing backoff time is determined to pause =20
the connection. No requests are sent to the node during the backoff =20
time to prevent putting further load on it.
-> However, Matthew Toseland writes in his work =20
http://www.toselandcs.co.uk/flogmirror/mjt92-diss-final.pdf that also =20
a message is sent back to the request initiator in this case.
=3D> I would like to know, what is the purpose of this message?
=3D> Does the request initiator react in some way in this situation?

Best regards,
Philipp