(spotted at http://pastethis.i2p/show/2280/ and jcpuid already matches
*FreeBSD* so this fixes a minor consistency issue. Thanks to the anonymous
paster.)
The bug has been there forever but never happened before
0.9.3 because the buffers were all 32KB and the largest
fragment was about 1500 bytes. In 0.9.3, there are multiple
buffer sizes, the smallest is 512 bytes, and a packet
of exactly 512 bytes would be silently dropped.
Thanks zab for finding it.
In my testing:
32 bit Windows (and, of course, 32 bit JRE) = Java added to the PATH
64 bit Windows and 64 bit JRE = Java added to the PATH
64 bit Windows and 32 bit JRE = Java *not* added to the PATH.
So...with this check-in:
- If the environment variable JAVA is set in the script, we'll use that
manually specified Java. We will not look in the registry, but we'll check to
make sure that the binary exists.
- If Java is found in the system path, we'll use it instead. We will not look in the
registry.
- If the variable is not set manually and Java is not in the system path we'll
look in the registry to find the java binary.
I've tested this in Windows XP, Vista, and 7 but it should work in any supported version
of Windows.
I've failed to get in contact with him for a renewal of his certificate. Errors might appear in logs
on installs after that date, just remove https://euve5653.vserver.de from /configreseed in console
and you wont get errors.
- More DHT limits
- Announce to backup trackers if DHT is empty
- Use PEX and DHT info in torrent peer count
- Don't use temp files for announces
- TrackerClient refactoring
- cleanups
- Better fix for logging dropped messages (ticket #758)
- Implement fast receive to reduce per-message handshakes
- Make messageReliability=none the default
*Behaviors.scala should really go in net.i2p.update.* in core, but ScalaTest
doesn't seem to be picking up the cross-dependency properly and just ignores
any Spec which includes them; they will move once the build.xml is fixed.
