Re: Questions on Freenet - Second Try
I will try to fill in the gaps ... On Mon, 2017-05-01 at 19:53 -0400, Steve Dougherty wrote: > > Original Message > > Subject: Re: Questions on Freenet - Second Try > > Local Time: May 1, 2017 7:43 PM > > UTC Time: May 1, 2017 11:43 PM > > From: st...@asksteved.com > > To: Discussion of development issues , phil > > ipp.spei...@uni-ulm.de > > > > > -------- Original Message > > > Subject: Questions on Freenet - Second Try > > > Local Time: April 25, 2017 8:14 AM > > > UTC Time: April 25, 2017 12:14 PM > > > From: philipp.spei...@uni-ulm.de > > > To: Support > > > Devl@freenetproject.org > > > Path Folding and Connection Managment: > > > > > > - Is it required that the data source actually starts to send a > > > "path > > > folding" offer back along the path or might any node on the path > > > simply decide to send its node reference back along the path, > > > hoping > > > to get new connections? > > > > It is my guess that a path folding offer can come from any node > > along the path. > > It is also how I remember it working. > > > - Does the data source always send the "path folding" offer back > > > or is > > > it possible to omit this. If the latter is the case, does this > > > imply > > > that there is no chance for creating new connections on this > > > particular path? > > > > I think it can be omitted. > > It can definitely be omitted (darknet), and as said above, any node on the path might make an offer. > > > - If one node answers the "path folding" offer and a new > > > connection is > > > created, is this "path folding" offer then passed back further > > > along > > > the path or does it stop at that node? > > > > I don't know. > > The request backtracks "the normal way" back to the initiator (taking a shortcut would cause havoc as it wouldn't kill the request). The offer made by the nodes on the paths are encrypted against the initiator's key IIRC (so only the initiator can decrypt/decide to peer). Several offers can be "bundled" with the response. It would be good to look into the details here... > > > - When connecting to a new node, how is the Friend-of-a-Friend > > > information (i.e. the locations of the node's neighbors) > > > exchanged? > > The only message type I've noticed that looks relevant is this one: ht > tps://github.com/freenet/fred/blob/build01478/src/freenet/io/comm/DMT. > java#L1345 > > I have not verified it's actually in use as such. > There is that and a few other things sent upon handshake https://github.com/freenet/fred/blob/next/src/freenet/node/PeerNode.java#L2258 > > > - Churn leads to frequent changes in the neighborhood of a node. > > > How > > > is the Friend-of-a-Friend information maintained to keep the > > > maintenance overhead small? > > You mean in terms of transfer of that information? > I don't think that we do any better than the obvious here. We send to each of our peers our location and a list of all of our peer's locations each time one of our connection status changes. I don't think that we do so when we are notified that one of our peer's peer location has changed (but check, don't take my word for it). (150+1)*8 bytes maximum I don't remember if we throttle it; I don't think we do; maybe we should. > > > Freenet's Load Balancing: > > > > > > - Relaying a request requires to keep track of it, i.e. the node > > > needs > > > to store information to be able to return the corresponding > > > response > > > at a later time. Due to resource limitations, a node cannot > > > accept > > > arbitrary requests and maintain state for them. > > > > > > -> So, requests can actually decide to reject a request depending > > > on > > > their current load. The corresponding connection is marked as > > > "backed > > > off", i.e. an exponential growing backoff time is determined to > > > pause > > > the connection. No requests are sent to the node during the > > > backoff > > > time to prevent putting further load on it. > > > -> However, Matthew Toseland writes in his work > > > http://www.toselandcs.co.uk/flogmirror/mjt92-diss-final.pdf that > > > also > > > a message is sent back to the request initiator in this
Re: Questions on Freenet - Second Try
Sorry; I managed to send this message before I was done with it. Original Message Subject: Re: Questions on Freenet - Second Try Local Time: May 1, 2017 7:43 PM UTC Time: May 1, 2017 11:43 PM From: st...@asksteved.com To: Discussion of development issues , philipp.spei...@uni-ulm.de I'm not confident in my answers; I will provide guesses where I have them. For better results you'll either have to hope someone more knowledgeable than I answers you, or read the source code. https://github.com/freenet/fred Original Message Subject: Questions on Freenet - Second Try Local Time: April 25, 2017 8:14 AM UTC Time: April 25, 2017 12:14 PM From: philipp.spei...@uni-ulm.de To: Support Devl@freenetproject.org Hello Unfortunately, my previously transmitted questions have not been answered so far. Maybe the large amount of questions was daunting. I have reduced it to a few questions which can be answered, hopefully, in a straightforward fashion. Path Folding and Connection Managment: - Is it required that the data source actually starts to send a "path folding" offer back along the path or might any node on the path simply decide to send its node reference back along the path, hoping to get new connections? It is my guess that a path folding offer can come from any node along the path. - Does the data source always send the "path folding" offer back or is it possible to omit this. If the latter is the case, does this imply that there is no chance for creating new connections on this particular path? I think it can be omitted. - If one node answers the "path folding" offer and a new connection is created, is this "path folding" offer then passed back further along the path or does it stop at that node? I don't know. - When connecting to a new node, how is the Friend-of-a-Friend information (i.e. the locations of the node's neighbors) exchanged? The only message type I've noticed that looks relevant is this one: https://github.com/freenet/fred/blob/build01478/src/freenet/io/comm/DMT.java#L1345 I have not verified it's actually in use as such. - Churn leads to frequent changes in the neighborhood of a node. How is the Friend-of-a-Friend information maintained to keep the maintenance overhead small? You mean in terms of transfer of that information? Freenet's Load Balancing: - Relaying a request requires to keep track of it, i.e. the node needs to store information to be able to return the corresponding response at a later time. Due to resource limitations, a node cannot accept arbitrary requests and maintain state for them. -> So, requests can actually decide to reject a request depending on their current load. The corresponding connection is marked as "backed off", i.e. an exponential growing backoff time is determined to pause the connection. No requests are sent to the node during the backoff time to prevent putting further load on it. -> However, Matthew Toseland writes in his work http://www.toselandcs.co.uk/flogmirror/mjt92-diss-final.pdf that also a message is sent back to the request initiator in this case. => I would like to know, what is the purpose of this message? https://github.com/freenet/fred/blob/build01478/src/freenet/io/comm/DMT.java#L473 ? My expectation is to have an explicit feedback mechanism instead of an implicit one based on lack of results. => Does the request initiator react in some way in this situation? I'm not certain about that either. I would expect it prompts backoff; there are probes for RejectedOverload percentages.
Re: Questions on Freenet - Second Try
I'm not confident in my answers; I will provide guesses where I have them. For better results you'll either have to hope someone more knowledgeable than I answers you, or read the source code. https://github.com/freenet/fred Original Message Subject: Questions on Freenet - Second Try Local Time: April 25, 2017 8:14 AM UTC Time: April 25, 2017 12:14 PM From: philipp.spei...@uni-ulm.de To: Support Devl@freenetproject.org Hello Unfortunately, my previously transmitted questions have not been answered so far. Maybe the large amount of questions was daunting. I have reduced it to a few questions which can be answered, hopefully, in a straightforward fashion. Path Folding and Connection Managment: - Is it required that the data source actually starts to send a "path folding" offer back along the path or might any node on the path simply decide to send its node reference back along the path, hoping to get new connections? It is my guess that a path folding offer can come from any node along the path. - Does the data source always send the "path folding" offer back or is it possible to omit this. If the latter is the case, does this imply that there is no chance for creating new connections on this particular path? I think it can be omitted. - If one node answers the "path folding" offer and a new connection is created, is this "path folding" offer then passed back further along the path or does it stop at that node? I don't know. - When connecting to a new node, how is the Friend-of-a-Friend information (i.e. the locations of the node's neighbors) exchanged? - Churn leads to frequent changes in the neighborhood of a node. How is the Friend-of-a-Friend information maintained to keep the maintenance overhead small? Freenet's Load Balancing: - Relaying a request requires to keep track of it, i.e. the node needs to store information to be able to return the corresponding response at a later time. Due to resource limitations, a node cannot accept arbitrary requests and maintain state for them. -> So, requests can actually decide to reject a request depending on their current load. The corresponding connection is marked as "backed off", i.e. an exponential growing backoff time is determined to pause the connection. No requests are sent to the node during the backoff time to prevent putting further load on it. -> However, Matthew Toseland writes in his work http://www.toselandcs.co.uk/flogmirror/mjt92-diss-final.pdf that also a message is sent back to the request initiator in this case. => I would like to know, what is the purpose of this message? => Does the request initiator react in some way in this situation? Best regards, Philipp
Re: Questions on Freenet - Second Try
Original Message Subject: Questions on Freenet - Second Try Local Time: April 25, 2017 8:14 AM UTC Time: April 25, 2017 12:14 PM From: philipp.spei...@uni-ulm.de To: Support Devl@freenetproject.org Hello Unfortunately, my previously transmitted questions have not been answered so far. Maybe the large amount of questions was daunting. I have reduced it to a few questions which can be answered, hopefully, in a straightforward fashion. Hi Phillip, Sorry about that - my recollection was that someone had replied to your initial mail, but I can't find any evidence that actually happened. I think we were also having some configuration difficulties around the mailing list after transitioning from a VPS to AWS. I don't have time right this second to reply to your questions, but if someone else doesn't in the next few days I expect to have enough time next week. - Steve Path Folding and Connection Managment: - Is it required that the data source actually starts to send a "path folding" offer back along the path or might any node on the path simply decide to send its node reference back along the path, hoping to get new connections? - Does the data source always send the "path folding" offer back or is it possible to omit this. If the latter is the case, does this imply that there is no chance for creating new connections on this particular path? - If one node answers the "path folding" offer and a new connection is created, is this "path folding" offer then passed back further along the path or does it stop at that node? - When connecting to a new node, how is the Friend-of-a-Friend information (i.e. the locations of the node's neighbors) exchanged? - Churn leads to frequent changes in the neighborhood of a node. How is the Friend-of-a-Friend information maintained to keep the maintenance overhead small? Freenet's Load Balancing: - Relaying a request requires to keep track of it, i.e. the node needs to store information to be able to return the corresponding response at a later time. Due to resource limitations, a node cannot accept arbitrary requests and maintain state for them. -> So, requests can actually decide to reject a request depending on their current load. The corresponding connection is marked as "backed off", i.e. an exponential growing backoff time is determined to pause the connection. No requests are sent to the node during the backoff time to prevent putting further load on it. -> However, Matthew Toseland writes in his work http://www.toselandcs.co.uk/flogmirror/mjt92-diss-final.pdf that also a message is sent back to the request initiator in this case. => I would like to know, what is the purpose of this message? => Does the request initiator react in some way in this situation? Best regards, Philipp
Questions on Freenet - Second Try
Hello Unfortunately, my previously transmitted questions have not been answered so far. Maybe the large amount of questions was daunting. I have reduced it to a few questions which can be answered, hopefully, in a straightforward fashion. Path Folding and Connection Managment: - Is it required that the data source actually starts to send a "path folding" offer back along the path or might any node on the path simply decide to send its node reference back along the path, hoping to get new connections? - Does the data source always send the "path folding" offer back or is it possible to omit this. If the latter is the case, does this imply that there is no chance for creating new connections on this particular path? - If one node answers the "path folding" offer and a new connection is created, is this "path folding" offer then passed back further along the path or does it stop at that node? - When connecting to a new node, how is the Friend-of-a-Friend information (i.e. the locations of the node's neighbors) exchanged? - Churn leads to frequent changes in the neighborhood of a node. How is the Friend-of-a-Friend information maintained to keep the maintenance overhead small? Freenet's Load Balancing: - Relaying a request requires to keep track of it, i.e. the node needs to store information to be able to return the corresponding response at a later time. Due to resource limitations, a node cannot accept arbitrary requests and maintain state for them. -> So, requests can actually decide to reject a request depending on their current load. The corresponding connection is marked as "backed off", i.e. an exponential growing backoff time is determined to pause the connection. No requests are sent to the node during the backoff time to prevent putting further load on it. -> However, Matthew Toseland writes in his work http://www.toselandcs.co.uk/flogmirror/mjt92-diss-final.pdf that also a message is sent back to the request initiator in this case. => I would like to know, what is the purpose of this message? => Does the request initiator react in some way in this situation? Best regards, Philipp
