Re: [Mldonkey-users] Questions about the edonkey protocol

[Michael Kroez]

Norbert LATAILLE wrote:

> In overnet, BCP of type "bcp://md4:ip:port" is sent when the source
> sender is firewalled. The ip:port is the address of the "refering peer"
> to which you can send an UDP request 0x18. It seems that the firwalled
> client is then instructed to connect to your TCP port in order to upload
> the file. According to your explainations, it seems that such firewalled
> case could be added quit easyly to mldonkey. Do you agree ?

Well. I think, this can be done in an quick and easy or in a better way.
(the following function names occur in donkeyClient.ml)

1. quick and easy
As soon as you have the referring bcp, you can send the 0x18 to the 
referring peer
and do nothing more than this. The refererring bcp is lost then, but 
hopefully the
connection will be established.
This is the way, mldonkey handles lowid sources sent from the server.
(query_locations_reply calls query_id for every source where the ip is not
valid - these are the lowid ones - and request a callback with this).
This is okay (for plain donkey), as the servers are periodically queried for
sources and the lowid id ones are sent hopefully more than once if the 
connect
does not occur.
For overnet the call request via the referring peer may be done only once.
2. better way
Save the referring peer in the clients type and identify that the client has
to be called inderectly (via the overnet udp message) and cannot be 
connected
directly.
There comes up the issue with the location kind I stated in the former post.
Mldonkey knows two location kinds (Known_location and Indirect_location) 
that
identify a peer.
Known_locations are identified with ip and port, Indirect_locations are 
identified
with md4 and the name (but not the referring donkey server/overnet peer).
An Indirect_location is created for all incoming connections and not 
only for
indirect ones behind a firewall. Therefore it never gets scheduled.
(See in read_first_message at Connect.req: 
new_client(Indirect_location(md4, name)
- this is the only place, where Indirect_location is used for creating 
a client).
This ambiguousity should be solved to use the two ways of identifiying a 
peer in
a better way.


A question from my side:
I tried something like this
http://mail.gnu.org/pipermail/mldonkey-users/2002-December/001704.html
(but it won't work with edonkey as the servers only support callbacks 
only for lowid
hosts).
Do you think this may be possible with overnet?
For edonkey (and probably overnet) a firewalled user can reach someone 
else but is not
reachable by others.
My case is vice versa: My client can be reached by everyone but can't 
connect to every port.
What I think of is to issue the search request with some sort of *can't 
connect to these ports*
option and get a referring bcp for all hosts using these ports.

Michael.