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

Reply via email to