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 ------------------------------------------------------------------------- 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
