- Sep 02, 2005
-
- Sep 01, 2005
-
-
-
* Don't publish leaseSets to the netDb if they will never be looked for - namely, if they are for destinations that only establish outbound streams. I2PTunnel's 'client' and 'httpclient' proxies have been modified to tell the router that it doesn't need to publish their leaseSet (by setting the I2CP config option 'i2cp.dontPublishLeaseSet' to 'true'). * Don't publish the top 10 peer rankings of each router in the netdb, as it isn't being watched right now.
-
* Don't publish leaseSets to the netDb if they will never be looked for - namely, if they are for destinations that only establish outbound streams. I2PTunnel's 'client' and 'httpclient' proxies have been modified to tell the router that it doesn't need to publish their leaseSet (by setting the I2CP config option 'i2cp.dontPublishLeaseSet' to 'true'). * Don't publish the top 10 peer rankings of each router in the netdb, as it isn't being watched right now.
-
- Aug 31, 2005
-
- Aug 30, 2005
-
- Aug 27, 2005
-
- Aug 25, 2005
-
- Aug 24, 2005
-
-
* Catch errors with corrupt tunnel messages more gracefully (no need to kill the thread and cause an OOM...) * Don't skip shitlisted peers for netDb store messages, as they aren't necessarily shitlisted by other people (though they probably are). * Adjust the netDb store per-peer timeout based on each particular peer's profile (timeout = 4x their average netDb store response time) * Don't republish leaseSets to *failed* peers - send them to peers who replied but just didn't know the value. * Set a 5 second timeout on the I2PTunnelHTTPServer reading the client's HTTP headers, rather than blocking indefinitely. HTTP headers should be sent entirely within the first streaming packet anyway, so this won't be a problem. * Don't use the I2PTunnel*Server handler thread pool by default, as it may prevent any clients from accessing the server if the handlers get blocked by the streaming lib or other issues. * Don't overwrite a known status (OK/ERR-Reject/ERR-SymmetricNAT) with Unknown.
-
- Aug 23, 2005
-
-
* Removed the concept of "no bandwidth limit" - if none is specified, its 16KBps in/out. * Include ack packets in the per-peer cwin throttle (they were part of the bandwidth limit though). * Tweak the SSU cwin operation to get more accurrate estimates under congestions. * SSU improvements to resend more efficiently. * Added a basic scheduler to eepget to fetch multiple files sequentially.
-
* Removed the concept of "no bandwidth limit" - if none is specified, its 16KBps in/out. * Include ack packets in the per-peer cwin throttle (they were part of the bandwidth limit though). * Tweak the SSU cwin operation to get more accurrate estimates under congestions. * SSU improvements to resend more efficiently. * Added a basic scheduler to eepget to fetch multiple files sequentially.
-
- Aug 22, 2005
-
- Aug 21, 2005
-
- Aug 20, 2005
-
- Aug 17, 2005
-
-
* Revise the SSU peer testing protocol so that Bob verifies Charlie's viability before agreeing to Alice's request. This doesn't work with older SSU peer test builds, but is backwards compatible (older nodes won't ask newer nodes to participate in tests, and newer nodes won't ask older nodes to either).
-
* Revise the SSU peer testing protocol so that Bob verifies Charlie's viability before agreeing to Alice's request. This doesn't work with older SSU peer test builds, but is backwards compatible (older nodes won't ask newer nodes to participate in tests, and newer nodes won't ask older nodes to either).
-
- Aug 16, 2005
-
- Aug 15, 2005
-
- Aug 14, 2005
-
- Aug 12, 2005
-
-
* Keep detailed stats on the peer testing, publishing the results in the netDb. * Don't overwrite the status with 'unknown' unless we haven't had a valid status in a while. * Make sure to avoid shitlisted peers for peer testing. * When we get an unknown result to a peer test, try again soon afterwards. * When a peer tells us that our address is different from what we expect, if we've done a recent peer test with a result of OK, fire off a peer test to make sure our IP/port is still valid. If our test is old or the result was not OK, accept their suggestion, but queue up a peer test for later. * Don't try to do a netDb store to a shitlisted peer, and adjust the way we monitor netDb store progress (to clear up the high netDb.storePeers stat)
-
- Aug 10, 2005
-
-
* Deployed the peer testing implementation to be run every few minutes on each router, as well as any time the user requests a test manually. The tests do not reconfigure the ports at the moment, merely determine under what conditions the local router is reachable. The status shown in the top left will be "ERR-SymmetricNAT" if the user's IP and port show up differently for different peers, "ERR-Reject" if the router cannot receive unsolicited packets or the peer helping test could not find a collaborator, "Unknown" if the test has not been run or the test participants were unreachable, or "OK" if the router can receive unsolicited connections and those connections use the same IP and port.
-
- Aug 09, 2005
-
- Aug 08, 2005
-
-
-
"ERROR [eive on 8887] uter.transport.udp.UDPReceiver: Dropping inbound packet with 1 queued for 1912 packet handlers: Handlers: 3 handler 0 state: 2 handler 1 state: 2 handler 2 state: 2" state = 2 means all three handlers are blocking on udpReceiver.receive()) this can legitimately happen if the bandwidth limiter or router throttle chokes the receive for >= 1s.
-