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 ------------------------------------------------------------------------- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel