Work in progress.
Router-side I2CP mostly done.
Client-side I2CP mostly done but undecided on how to handle
listeners.
Streaming stubbed out but may be wrong, may need multiple socket managers,
not clear how to proceed.
I2PTunnel not started.
Blacklist of DSA-only dests not started.
Router leaseset publishing not correct. Not clear whether to have
additional tunnel pools with flags, or put the tunnel pools into
the client hashmap twice. Client config contains destination,
may need to move that to tunnel pool.
Prop from i2p.i2p.zzz.upnp, containing:
Cyberlink for Java v3.0 + (2015-02-15) from github
See branch revs for more info and fixups.
Previous was Cyberlink for Java v2.1 (2011-09-16) from SVN.
From a scan of the 2.1-to-3.0 diff, it's mostly
formatting changes, getting rid of DOS line endings,
and a couple of new features we don't need.
I see very few fixes. And the Device.getAbsoluteURL()
"fixes" did not work in my testing, I had to fix them again.
Unlikely to fix any of the open UPnP tickets #481#725#728#1194#1480.
But now we're current.
- Send exploratory lookups directly to the floodfill if
we are already connected to him
- Don't encrypt RI lookups when overloaded
- Don't explore when overloaded
- SearchJob cleanups
Tunnels: Drop instead of reject requests on high job lag
Unmodified cybergarage-upnp from github rev 9499b03 2015-02-05
https://github.com/cybergarage/cybergarage-upnp/commits/master
which is the same as rev 3ed1af9 2014-07-28 except for
the addition of README.md which we aren't using.
This is post-version 3.0.
Omitted files:
router/java/src/org/cybergarage/xml/parser/XercesParser.java
router/java/src/org/cybergarage/xml/parser/XmlPullParser.java
router/java/src/org/cybergarage/xml/parser/kXML2Parser.java
chmod all files back to 644.
Diverging from 2.1 checkin rev 59eae97dbb470d8c4a1e4dba3a9763e134bb0c53
in prep for merging.
License unchanged.
Compile tested only.
- Use lifetime average value for job lag
- Change the job lag limit to less than 25ms
- Consider and set the limit of backlogged tunnels to less than 5
receiving a message. Possible workaround for tickets #551, #1075, #1411.
Root cause of problem not yet found.
- Increase threshold for loop throttle, this probably isn't the problem.
- Log tweaks
