Re: [Mldonkey-users] Indirect locations support

[MLdonkey]

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

QueryCallUDP is for sources that are received by UDP (ie the server is
not connected).

>  I'm working on a callback feature to call clients because they are not 
>  reachable  by my client(ports filtered).

This is a very good idea, but I don't think it can work this
way. Indeed, servers only allows indirect connections to their LowID
clients, ie they won't understand a QueryID or QueryCallUDP for an IP
address. 

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

See above :(

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

No, they are only sources that we know an IP and port to connect
them. Either because they are HighID, or because they connected to us
and give us an IP:port to reach them. Real LowID should never arrive
there.

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

You could also detect the black-listed port when you want to connect,
and issue an indirect-connect message to the server at that moment,
and when the connection is done, mldonkey will recognize that the
client is the known one, not an Indirect_location.

>  P.S. mldonkey code is somewhat complicated.

Really, I did my best to write it simple. But, then, I made a lot of
small changes to fix bugs and add features, and now it is very uggly :)

- MLDonkey