gtk-gnutella-devel Digest, Vol 23, Issue 2
|
View:
New views
1 Messages
—
Rating Filter:
Alert me
|
 |
gtk-gnutella-devel Digest, Vol 23, Issue 2
by gtk-gnutella-devel-request
::
Rate this Message:
Send gtk-gnutella-devel mailing list submissions to
gtk-gnutella-devel@... To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel or, via email, send a message with subject or body 'help' to gtk-gnutella-devel-request@... You can reach the person managing the list at gtk-gnutella-devel-owner@... When replying, please edit your Subject line so it is more specific than "Re: Contents of gtk-gnutella-devel digest..." Today's Topics: 1. Re: GUID reliably has IPv4 at [0-4] still? (Christian Biere) 2. Re: Encryption and what is/isn't (Christian Biere) 3. Re: GUID reliably has IPv4 at [0-4] still? (Matthew Lye) 4. Re: GUID reliably has IPv4 at [0-4] still? (Raphael Manfredi) 5. Re: GUID reliably has IPv4 at [0-4] still? (Matthew Lye) 6. DHT implementation in gtk-gnutella (Raphael Manfredi) 7. Re: GUID reliably has IPv4 at [0-4] still? (Christian Biere) 8. Updated Norwegian translation (Alexander Nicolaysen S?rnes) 9. Re: Updated Norwegian translation (Raphael Manfredi) ---------------------------------------------------------------------- Message: 1 Date: Tue, 1 Jul 2008 19:18:26 +0200 From: Christian Biere <christianbiere@...> Subject: Re: [gtk-gnutella-devel] GUID reliably has IPv4 at [0-4] still? To: gtk-gnutella-devel@... Message-ID: <20080701171826.GE865@cyclonus> Content-Type: text/plain; charset=utf-8 Matthew Lye wrote: > I've been 'implementing' browsing of proxied hosts via command line/ > search field[1]. > The menu interface uses data from the original selected item to name > the search entry after that address. > It seems impossible to derive the local address from the GUID of the > host. > (a) Is guid_oob_get_addr_port(...)[2,3] broken, > (b) am I making a semantic error with *guid (assuming that it > is a raw 16-byte guid), > or > (c) does no-one ever encode the network bytes anymore? You might be confusing the MUID with the ServentID. The latter doesn't contain a port number or an IP address. The MUID contains the IPv4 address in queries if the querying peer or its proxying ultrapeer support and request out-of-band results (query hits). > In other instances, they seem to still be being relied upon for some > filtering of fake or impossible GUIDs from hosts. > [1] via search_common.c:3100, search_gui_new_browse_host(...). > [2] explicitly, guid.c:434, guid_oob_get_addr_port(...) > [3] called by: > oob_got_results(...)@oob.c: 656, > build_search_msg(...)@search.c:2346 g, > and search_request_preprocess(...)@search.c:5150 I'm not sure that I understand what you're trying to achieve. What information do you have about the peer you want to browse? Do you know its ServentID? Do you know its IP address? Do you know its listening port? -- Christian ------------------------------ Message: 2 Date: Tue, 1 Jul 2008 19:24:15 +0200 From: Christian Biere <christianbiere@...> Subject: Re: [gtk-gnutella-devel] Encryption and what is/isn't To: gtk-gnutella-devel@... Message-ID: <20080701172415.GF865@cyclonus> Content-Type: text/plain; charset=utf-8 xiando wrote: > > The world is getting more deep packet inspection happy. The obvious > > next step is more routine use of encryption. I notice GTKG links > > against TLS already. Will it use encryption for all connections? > A relevant article: "'Yes' to surveillance law", > http://www.thelocal.se/12534/20080618/ > "Swedish lawmakers voted late on Wednesday in favour of a controversial bill > allowing all emails and phone calls to be monitored in the name of national > security." > The Swedish regime are about to monitor all contact you and your loved ones > have with people within the regime. This means that if your gtk-gnutella > software connects to someone within that regime then the regimes FRA agency > will record and study your TCP/UDP packets. Social problems can't be fixed in software. They require hardware solutions. For the record, your cryptographic signature is "bad". -- Christian ------------------------------ Message: 3 Date: Tue, 1 Jul 2008 14:14:33 -0400 From: Matthew Lye <mlye@...> Subject: Re: [gtk-gnutella-devel] GUID reliably has IPv4 at [0-4] still? To: gtk-gnutella-devel@... Message-ID: <A7906D5D-3F53-43C0-AE42-0879F28E5EB8@...> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes On 1-Jul-08, at 1:18 PM, Christian Biere wrote: > Matthew Lye wrote: >> I've been 'implementing' browsing of proxied hosts via command line/ >> search field[1]. >> The menu interface uses data from the original selected item to name >> the search entry after that address. >> It seems impossible to derive the local address from the GUID of the >> host. > >> (a) Is guid_oob_get_addr_port(...)[2,3] broken, >> (b) am I making a semantic error with *guid (assuming that it >> is a raw 16-byte guid), >> or >> (c) does no-one ever encode the network bytes anymore? > > You might be confusing the MUID with the ServentID. The latter > doesn't contain a port number or an IP address. The MUID contains the > IPv4 address in queries if the querying peer or its proxying ultrapeer > support and request out-of-band results (query hits). I believe that I'm working with [what is consistently named] the GUID [subsequently referred to as ServentID for disambiguation]. I've confirmed identity via the details view in GTKG. > I'm not sure that I understand what you're trying to achieve. What > information do you have about the peer you want to browse? > Do you know its ServentID? > Do you know its IP address? > Do you know its listening port? I believe that all I know is (a) the ServentID [formerly GUID], a 16 hexadecimal digit string, and (b) a set of IPv4 addresses of recent proxies of that Servent. My main objective is to accomplish re-connection/persistence between X11 crashes [not due to GTKG at all], which has been achieved; sending the GUID to the proxies in a command line browse request. i.e, "browse:f00df00df00df00d: 11.111.111.111:6036,22.222.222.222:6036,33.333.333.333:6036" [ugly but unambiguous.] [p.s. one can try to force tls (browse:tls:blah blah blah...), per the other thread; not sure this is documented.] I wish, as a secondary objective, to label the browse search results with the IPv4:port, as happens when one selects 'browse host' from a pop-up menu, for persistence of labeled identity. This GUI activity uses query result data to determine the IPv4:port. I am attempting to recover this data from the ServentID, and receive improbable IP addresses as a result. It may - but does not seem, to my sideline tinkerings with byte switching, et cetera - to be an endian issue. > -- > Christian -- Net Neutralitarian ------------------------------ Message: 4 Date: Wed, 2 Jul 2008 09:15:11 +0000 (UTC) From: Raphael_Manfredi@... (Raphael Manfredi) Subject: Re: [gtk-gnutella-devel] GUID reliably has IPv4 at [0-4] still? To: gtk-gnutella-devel@... Message-ID: <g4fguu$1h6$1@...> Content-Type: text/plain; charset="iso-8859-1" Quoting Matthew Lye <mlye@...> from ml.softs.gtk-gnutella.devel: :I am attempting to recover this data from the ServentID, and receive :improbable IP addresses as a result. :It may - but does not seem, to my sideline tinkerings with byte :switching, et cetera - to be an endian issue. As Christian already said, the GUID is a pure random number which is not encoding any IP address within it. The only place whare we do encode the IP addresses is in the MUID (Message Unique ID), located in the Gnutella header of queries for which we want an OOB reply. Raphael ------------------------------ Message: 5 Date: Wed, 2 Jul 2008 06:07:32 -0400 From: Matthew Lye <mlye@...> Subject: Re: [gtk-gnutella-devel] GUID reliably has IPv4 at [0-4] still? To: gtk-gnutella-devel@... Message-ID: <DE30FAC1-661C-4B4D-92AB-8059804D8B5B@...> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes On 2-Jul-08, at 5:15 AM, Raphael Manfredi wrote: > As Christian already said, the GUID is a pure random number which is > not > encoding any IP address within it. If I understand correctly now... (a) MUID implies GUID. A GUID is just any old 16-byte string that happens to be guaranteed to be unique. Got it. [Probably not the most efficient way to learn about atoms.] (b) the following is actually speaking exclusively of MUIDs and should perhaps be clearer: from guid.c:426-434: > /** > * Extract the IP and port number from the GUID of queries marked for > OOB > * query hit delivery. > * > * Bytes 0 to 3 of the guid are the 4 octet bytes of the IP address. > * Bytes 13 and 14 are the little endian representation of the port. > */ > void > guid_oob_get_addr_port(const gchar *guid, host_addr_t *addr, guint16 > *port) (c) The GUID which I *can* reliably use when calling search_gui_new_browse_host(...) to solicit a response through a firewall in a browse request - and hence hadn't been thinking of as random - is generated uniquely the first time a client ever runs as a purely random number and subsequently shouldn't change, ideally, but it can. The span of its duration exceeds the span of its utility by several magnitudes, giving it an unwonted salience. Analogous in some ways to the calcification of dynamic IP addresses. ...yes? ------------------------------ Message: 6 Date: Fri, 04 Jul 2008 20:24:39 +0200 From: Raphael Manfredi <Raphael_Manfredi@...> Subject: [gtk-gnutella-devel] DHT implementation in gtk-gnutella To: gtk-gnutella-devel@... Message-ID: <13203.1215195879@...> Hello Gnutella fans, I want to inform you that I have begun yesterday the implementation of the DHT for gtk-gnutella, in a way that I hope will be compatible with LimeWire's. The Kademlia implementation itself is complex but should be rather straightforward. The real challenge will be in areas where LimeWire has not fully documented what they are doing: who publishes what, when, and in which format. However, that is "user-level" stuff, so to speak, and my aim for now is to be able to implement the DHT core correctly and to see how it behaves in terms of traffic and resource consumption (disk, memory, CPU). Cheers, Raphael ------------------------------ Message: 7 Date: Sat, 5 Jul 2008 00:43:50 +0200 From: Christian Biere <christianbiere@...> Subject: Re: [gtk-gnutella-devel] GUID reliably has IPv4 at [0-4] still? To: gtk-gnutella-devel@... Message-ID: <20080704224350.GB23947@cyclonus> Content-Type: text/plain; charset=utf-8 Matthew Lye wrote: > On 2-Jul-08, at 5:15 AM, Raphael Manfredi wrote: > > As Christian already said, the GUID is a pure random number which is > > not > > encoding any IP address within it. > > If I understand correctly now... > > (a) MUID implies GUID. A GUID is just any old 16-byte string that > happens to be guaranteed to be unique. Got it. > [Probably not the most efficient way to learn about atoms.] Yes, you can think of a GUID as a primitive data type or structure which is used either as ServentID or MessageUID. > (b) the following is actually speaking exclusively of MUIDs and should > perhaps be clearer: > from guid.c:426-434: > > /** > > * Extract the IP and port number from the GUID of queries marked for > > OOB > > * query hit delivery. > > * > > * Bytes 0 to 3 of the guid are the 4 octet bytes of the IP address. > > * Bytes 13 and 14 are the little endian representation of the port. > > */ > > void > > guid_oob_get_addr_port(const gchar *guid, host_addr_t *addr, guint16 > > *port) Yes, you can replace GUID with MUID here. See also how this function is used. > (c) The GUID which I *can* reliably use when calling > search_gui_new_browse_host(...) to solicit a response through a > firewall in a browse request - and hence hadn't been thinking of as > random - is generated uniquely the first time a client ever runs as a > purely random number and subsequently shouldn't change, ideally, but > it can. In newer version of gtk-gnutella a new ServentID is generated on each startup. In other software it's probably persistent after the initial installation. > The span of its duration exceeds the span of its utility by > several magnitudes, giving it an unwonted salience. Analogous in some > ways to the calcification of dynamic IP addresses. > ...yes? The average uptime of a peer is supposedly less than 2 hours. I don't think any software tries to establish persistent ultrapeer connections. So the peer might be long offline or simply not reachable through its previous ultrapeers if you want to browse it a couple of minutes or hours after receiving query hits from it. -- Christian ------------------------------ Message: 8 Date: Sun, 6 Jul 2008 14:53:38 +0200 From: Alexander Nicolaysen S?rnes <alex@...> Subject: [gtk-gnutella-devel] Updated Norwegian translation To: gtk-gnutella-devel@... Message-ID: <200807061453.39215.alex@...> Content-Type: text/plain; charset="iso-8859-1" Hello, Here is an updated Norwegian Bokm?l translation, including some fixes/improvements as well: http://www.thehandofagony.com/alex/oversetting/gtk-gnutella/gtk-gnutella-nb-svn-20080706.tar.bz2 Once again: thanks for this great software! Alexander N. S?rnes ------------------------------ Message: 9 Date: Mon, 7 Jul 2008 05:16:35 +0000 (UTC) From: Raphael_Manfredi@... (Raphael Manfredi) Subject: Re: [gtk-gnutella-devel] Updated Norwegian translation To: gtk-gnutella-devel@... Message-ID: <g4s8rj$6pv$1@...> Content-Type: text/plain; charset="iso-8859-1" Quoting "Alexander Nicolaysen =?iso-8859-1?q?S=F8rnes?=" :Once again: thanks for this great software! Thanks to you as well. Submitted in SVN. Raphael ------------------------------ ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ------------------------------ _______________________________________________ gtk-gnutella-devel mailing list gtk-gnutella-devel@... https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel End of gtk-gnutella-devel Digest, Vol 23, Issue 2 ************************************************* |
| Free embeddable forum powered by Nabble | Forum Help |
