under the assumption that they are already talking
to most of the routers, so there's no reason to reject. This may drive them
to their conn. limits, but it's hopefully a temporary solution to the
tunnel build congestion. As the net grows this will have to be revisited.
Under the one-packet-enough theory, and the fact that most
tunnels in a x+1 pool are of length x, variable lengths
don't really help that much. Also, a default of 1 led
to all sorts of problems with iMule/SAM, who was not
setting the variance properties.
This will affect exploratory tunnels for new users,
and those that have never saved a change on configtunnels.jsp,
and iMule users 1.4.5 and earlier.
- Move from a single connection limit threshold (80%) to
two (75% and 87%), and only start rejecting tunnels
at the higher threshold, to increase build success
- Move some limit methods from the transports to TransportImpl
- Add limit methods with a threshold argument
address to no address, so that inbound NTCP is disabled
after SSU detects a firewall. When UPnP was apparently successful
but the router is still firewalled (due to an additional
software firewall or a bad UPnP indication, for example)
the router will now remove the NTCP address.
* General cleanup on streaming and ministreaming.
This fixes some compile warnings, and prepares for a larger fix.
There is no code-flow changes, just lint. One warning remains as I am
unsure exactly how to solve the problem yet.
* Remove the last reference to my eepsite as a "news.xml" source,
and likewise stop my public key from being included
among valid release signing keys.
---------------------------------------------------------------------------------------
* netdb.jsp: Add country chart at bottom, clean up version chart
- Limit exploratory tunnels to connected peers when over
half the connection limit (was 80%)
- Have the high capacity tier fall back to a new connected tier
before moving on to the not failing tier
so that tunnel build success doesn't collapse
* PeerTestJob:
- Limit to connected peers
