Re: [Mldonkey-users] Indirect locations support

[Michael Kroez]

Pierre Etchemaite wrote:

> Le Mon, 02 Dec 2002 18:05:36 +0100, Michael Kroez <address@hidden> a écrit :
>  
>
> > does mldonkey support calling of indirect clients?
> > So, does mldonkey send callback requests to indirect clients
> > to request a connection or does it wait for being connected by them?
> > I searched a lot in the code, but haven't seen something
> > that looks like this. I would be thankful if someone can point
> > me to the code where this is realized.
> >    
>
> I think it only "dereference" indirect locations when it receives such
> location from a server (I don't think indirect locations are propagated, and
> we saw what happened when eMule tried to). See query_locations_reply in
> donkey/donkeyClient.ml.
Okay, I found this behaviour in the code.
If the server for a received location is connected to it uses that and sends
QueryID otherwise QueryCallUDP to the sending server.

I'm working on a callback feature to call clients because they are not 
reachable
by my client(ports filtered).
It should work like this:
1. Every incoming "direct location" with filtered ports is marked as 
blacklisted,
  the sending server_ip and server_port are saved
2. reconnect_client sends a Query for a callback to the server with the 
client
  id (normally this should be the lowid for QueryID)
3. wait for the incoming call for this location.

Do you think this is possible?
My questions are (to someone who might know...):
- What is the semantic difference of the QueryID and QueryCallUDP requests
 (especially in server behaviour)?
 The associated server sends QueryIDFailed (sent via a TCP conn to a 
server)
 for a real ip a.b.c.d.
 So I think QueryID is only good for looking up lowids local to the server.
 Then I switched over to use only QueryCallUDP but this is not much tested.

 Emule only supports QueryID (as OP_CALLBACKREQUEST)  and QueryIDReply
 (as OP_CALLBACKREQUESTED)  and uses this for their call handling for
 clients only with lowids but does not use the QueryCallUDP request at all.

This is the scheme that I assume:

           mldonkey             server                      
client(emule...)
Version 1.
           QueryID(id) ------->
                                QueryIDReply(ip,port) ---->    
                       <-----------------------------------TCP connect
                                           or
                       <------- QueryIDFailed(id)
Version 2.
           QueryCallbackUDP
           (ip, port, ip)------>
                                QueryIDReply(ip,port) ---->
                       <----------------------------------- TCP connect

- What is the difference between the location_kind
 Indirect_location and Known_location in mldonkey?
 As far as I know:
 - Known_location are all sources received (either directly or via 
dereferencing)
 - Indirect_locations are all (in)connecting clients (or friend clients),
   but we don't want to connect them.
 To point out for my thing:
   A called location is first an Indirect_location (when it connects) 
and should
   be mapped on the Known_location (with connection states and so on) 
used for
   calling.

Hope, someone has enlightning meanings to this.
Regards,
Michael.

P.S. mldonkey code is somewhat complicated.