LowID

Contents 1 LOWID explained 2 LOWID in MLdonkey interface 3 See also 4 ERROR: Your port 4662 is not reachable. You have a LOWID 5 LOWID Overnet peer ? 6 ulimit problems

LOWID explained

After succesfully connecting a donkey server, a donkey peer receives a 32bits integer identifier, assigned by this server, that is either a HighID or a LowID.

Corollary: Until a peer connects to a server, it has neither a HighID nor a LowID to talk about (see enable_servers)

A HighID is just the peer's IP address quad interpreted in little-endian order (i.e. with bytes reversed). Peers that are directly connected to the Internet (and thus can be reached directly by other peers) should receive a HighID (matching their external IP address) from the connected servers.

Peers that cannot be reached directly (they are firewalled or located behind a router) are assigned a LowID by the server(s) they're connected to. LowIDs are opaque integers that only make sense to the server that assigned them.

The highest byte of LowID identifiers is always 0 (hence the name: they're usually smaller than their HighID counterparts). A consequence of that poor network design choice is that peers whose IP address ends with a 0 cannot get a HighID (because their HighID would be interpreted as a LowID).

If HighID peer 'A' wants to connect to LowID peer 'B':

• it asks the server for a 'callback' (remember only the server can contact 'B').
• The server forwards this connection request to LowID peer 'B' (obv. telling 'B' the address of peer 'A').
• Peer 'B' then 'calls back'/connects peer 'A'.

So there are the following connection combinations of peers:

• HighID <--> HighID: no problem, full destination address known
• HighID <--> LowID: no problem, either full destination address known or initiated as callback
• LowID <--> LowID: no connection possible, two LowID peers are unable to communicate with each other

Beside that, another drawback associated with LowIDs stems from the fact that servers must spend a certain amount of time relaying connection requests to LowID peers; to avoid excessive loads, many servers only allow a small number of LowID clients, if any. That said, it's quite obvious that situations in which your client gets LowID should be avoided by all means.

Lugdunum Servers (the majority of eDonkey servers) attempt to verify if your advertised port is really open before assigning a HighID or LowID to your peer. If the test fails for whatever reason (including the 8 seconds timeout), you'll get a LowID.

LOWID in MLdonkey interface

You can see your ID for each server you're connected to using the id command.

In sources lists, HighID sources are marked as "Direct" while LowID sources aren't.

See also

enable_servers, id, force_high_id. WhatFirewallPortsToOpen

ERROR: Your port 4662 is not reachable. You have a LOWID

First, check that your client port is really open using this test: [1]] (or, if that one isn't available, [[2]). If this test fails, check that your port is not firewalled (See Ports for all ports you should open in your firewall). If you're behind some gateway, be sure to map those ports to your box. Enabling force_client_ip and setting client_ip to your gateway public address may help too.

Often changing one of the options does the job: Either your mld is hashing and can't reply quick enough to server questions or server_connection_timeout may be to low (my setting is 30) thx to Meikel (Mailing-list)

Also, do not saturate your device (and specifically your uplink). Saturated devices add some lag, and it can be enough to trigger the 8 seconds timeout. Try reducing your max_hard_upload_rate, until you don't saturate anymore (or only seldomly).

If you use Linux TrafficShaping, you can see if your uplink is saturated, and even evaluate the lag:

$ /sbin/tc -s class ls dev ppp0
~[[...]]
class htb 1:30 parent 1:1 leaf 30: prio 3 rate 24Kbit ceil 114Kbit burst 2Kb cburst 1744b
 Sent 7665915 bytes 21421 pkts (dropped 11, overlimits 0)
 rate 9978bps 9pps backlog 6p
 lended: 10441 borrowed: 10974 giants: 0
 tokens: -393346 ctokens: -151543

If you see "backlog" (as in this example), you're saturating. The added delay is roughly backlog/pps: 6/9 = 0.66 s. That should be fine, but if your delay never goes below 1s, it could be enough to fail the test and get a LowID.

LOWID Overnet peer ?

Firewalled Overnet peer use a trick similar to the LowID one, but adapted to the lack of servers. Instead, they pick a random non-firewalled peer (a "buddy") that will forward the incoming connection queries.

ulimit problems

LOWID can also be a side effect of a too small ulimit value set (see [3]).

If after connecting to Connection test you get a message like this : "sent hello but the answer doesn't seem to come from an edonkey client", then try this :

$ ulimit -n 1024

before running mldonkey. ulimit -n sets the maximum file descriptor.