Re: issue with connecting two local peers
Martin Schanzenbach <[email protected]> Sun, 15 Dec 2024 22:45:39 +0100
| Newsgroups | gmane.network.gnunet.devel |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --------------B08fe0ICak2MbsKj6x99HQdr Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit It is our goal to have everything documented, of course. But we cannot force anybody to do anything. We are also not a project that has the luxury of rejecting contributions left and right for reasons such as "not documented". That being said I do share your sentiment. Everything that is created should be sufficiently documented. And that is especially true for tooling such as the testbed. Note that documentation is missing or is incomplete on various levels: - Protocol specification - C API/Developer Documentation - Usage/User guide I think we do not even have an open issue for the missing documentation. But even if we had right now, it would be so low on the list of things that must happen, it would probably not be tackled in the short term. So, unless the "creators" of the testbed document what they did and how they think it should be used in the handbook, somebody else would have to reverse engineer how it works and document it. Which will obviously take longer. It is what it is right now, and to quote a sentence from our release announcements: "As a result, [gnunet] is still *only suitable for early adopters with some reasonable pain tolerance*." -msc Am 15.12.24 um 20:53 schrieb gogo gogo: > > I also suggest to add guideline to force dev to test and to make doc > on ANYTHING they create. > > What do you all think of this idea please? > > > Le dim. 15 déc. 2024, 10:58, gogo gogo <[email protected]> a écrit : > > I definitely would like to use and maybe contribute to freenet > > > Le dim. 15 déc. 2024, 10:54, gogo gogo <[email protected]> a > écrit : > > Could you either document the second method or can you give me > the instruction to do it manually please? > > > Le dim. 15 déc. 2024, 10:43, Martin Schanzenbach > <[email protected]> a écrit : > > There are two ways of doing this in gnunet. > The first is to do it manually, by starting two peers with > different configurations and having them connect. > > But the proper way to do testing would be to use the (new) > testing API. > Alas, there is no usable documentation for either right now. > > BR > Martin > > On Sat, 2024-12-14 at 18:12 +0100, Maxime Devos wrote: >> >> If you wish to start multiple peers on one machine, you >> probably need to adjust the configuration more. >> >> * If things are still the same as when I last worked >> with this (and IIRC), some things are _/outside/_ >> GNUNET_HOME. There are some sockets … somewhere (I >> think under /tmp? Not sure where.). So, GNUnet might >> be getting confused from this. >> * Maybe wait a few seconds after doing ‘gnunet-arm […] >> -s’, instead of the &&. Maybe the TCP or UDP >> transports haven’t choosen a port yet? I’m not sure >> this is how it works though – not familiar with this, >> this is speculation. >> * I’m not sure if UDP ports are choosen automatically. >> If they aren’t, then there might be some kind of port >> conflic. In case of UDP (unidirectional), then the >> peers would be unable to verify each others existence. >> * Even if they are choosen automatically, this >> automation probably had NAT-punching in mind, not this. >> * For an isolated network, I think you also need to >> tell GNUnet to bind to ‘localhost’ instead of everything. >> >> It would be nice to have official documentation on >> setting up this kind isolated one-machine, multiple peers >> network. It seems quite convenient for safely testing >> things out. (Though for full isolation, a ‘unix’ >> transport would be needed.) >> >> Best regards, >> Maxime Devos >> > --------------B08fe0ICak2MbsKj6x99HQdr Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit <!DOCTYPE html> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body> <p>It is our goal to have everything documented, of course.</p> <p>But we cannot force anybody to do anything. We are also not a project that has the luxury of rejecting contributions left and right for reasons such as "not documented".</p> <p>That being said I do share your sentiment. Everything that is created should be sufficiently documented. And that is especially true for tooling such as the testbed. Note that documentation is missing or is incomplete on various levels:</p> <p>- Protocol specification</p> <p>- C API/Developer Documentation</p> <p>- Usage/User guide<br> </p> <p>I think we do not even have an open issue for the missing documentation. But even if we had right now, it would be so low on the list of things that must happen, it would probably not be tackled in the short term.</p> <p>So, unless the "creators" of the testbed document what they did and how they think it should be used in the handbook, somebody else would have to reverse engineer how it works and document it. Which will obviously take longer.</p> <p>It is what it is right now, and to quote a sentence from our release announcements:</p> <p>"As a result, [gnunet] is still <b>only suitable for early adopters with some reasonable pain tolerance</b>."</p> <p><br> </p> <p>-msc<br> </p> <div class="moz-cite-prefix">Am 15.12.24 um 20:53 schrieb gogo gogo:<br> </div> <blockquote type="cite" cite="mid:CAHYwvPicmjztA0ux-4YGVg9CHfH=g93Mu_b8auk7MR9fb4DeBQ@mail.gmail.com"> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> <p dir="ltr">I also suggest to add guideline to force dev to test and to make doc on ANYTHING they create.</p> <p dir="ltr">What do you all think of this idea please?</p> <br> <div class="gmail_quote gmail_quote_container"> <div dir="ltr" class="gmail_attr">Le dim. 15 déc. 2024, 10:58, gogo gogo <<a href="mailto:[email protected]" moz-do-not-send="true" class="moz-txt-link-freetext">[email protected]</a>> a écrit :<br> </div> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <p dir="ltr">I definitely would like to use and maybe contribute to freenet</p> <br> <div class="gmail_quote"> <div dir="ltr" class="gmail_attr">Le dim. 15 déc. 2024, 10:54, gogo gogo <<a href="mailto:[email protected]" target="_blank" rel="noreferrer" moz-do-not-send="true" class="moz-txt-link-freetext">[email protected]</a>> a écrit :<br> </div> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <p dir="ltr">Could you either document the second method or can you give me the instruction to do it manually please?</p> <br> <div class="gmail_quote"> <div dir="ltr" class="gmail_attr">Le dim. 15 déc. 2024, 10:43, Martin Schanzenbach <<a href="mailto:[email protected]" rel="noreferrer noreferrer" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">[email protected]</a>> a écrit :<br> </div> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div lang="NL-BE" link="blue" vlink="#954F72" style="word-wrap:break-word"> <div>There are two ways of doing this in gnunet.</div> <div>The first is to do it manually, by starting two peers with different configurations and having them connect.</div> <div><br> </div> <div>But the proper way to do testing would be to use the (new) testing API.</div> <div>Alas, there is no usable documentation for either right now.</div> <div><br> </div> <div>BR</div> <div>Martin</div> <div><br> </div> <div>On Sat, 2024-12-14 at 18:12 +0100, Maxime Devos wrote:</div> <blockquote type="cite" style="margin:0 0 0 .8ex;border-left:2px #729fcf solid;padding-left:1ex"> <div> <p class="MsoNormal">If you wish to start multiple peers on one machine, you probably need to adjust the configuration more. </p> <p class="MsoNormal"> </p> <ul style="margin-top:0cm" type="disc"> <li style="margin-left:0cm">If things are still the same as when I last worked with this (and IIRC), some things are _<i>outside</i>_ GNUNET_HOME. There are some sockets … somewhere (I think under /tmp? Not sure where.). So, GNUnet might be getting confused from this.</li> <li style="margin-left:0cm">Maybe wait a few seconds after doing ‘gnunet-arm […] -s’, instead of the &&. Maybe the TCP or UDP transports haven’t choosen a port yet? I’m not sure this is how it works though – not familiar with this, this is speculation.</li> <li style="margin-left:0cm">I’m not sure if UDP ports are choosen automatically. If they aren’t, then there might be some kind of port conflic. In case of UDP (unidirectional), then the peers would be unable to verify each others existence.</li> <li style="margin-left:0cm">Even if they are choosen automatically, this automation probably had NAT-punching in mind, not this.</li> <li style="margin-left:0cm">For an isolated network, I think you also need to tell GNUnet to bind to ‘localhost’ instead of everything.</li> </ul> <p class="MsoNormal"> </p> <p class="MsoNormal">It would be nice to have official documentation on setting up this kind isolated one-machine, multiple peers network. It seems quite convenient for safely testing things out. (Though for full isolation, a ‘unix’ transport would be needed.)</p> <p class="MsoNormal"> </p> <p class="MsoNormal">Best regards,<br> Maxime Devos</p> </div> </blockquote> <div><br> </div> <div><span></span></div> </div> </blockquote> </div> </blockquote> </div> </blockquote> </div> </blockquote> </body> </html> --------------B08fe0ICak2MbsKj6x99HQdr--