jrandom authored 20 years ago and zzz committed 20 years ago

dropped the old notice.jsp style result notification
display destination info on the left nav

jrandom authored 20 years ago and zzz committed 20 years ago

now allow restarting within the same jvm (loading all the config options again, rebinding sockets, etc - it does NOT fire up all the clientApp tasks though - those aren't part of the router)

shendaras authored 20 years ago and zzz committed 20 years ago

I marked all the empty statements with //nop
I removed unneccessary elses (ie, the if returns or throws)
I took out some casts (integral promotions/some didn't need to be there)
-- Love, shendaras
(2 in one day, w00t)

shendaras authored 20 years ago and zzz committed 20 years ago

Note:  I didn't touch routerconsole since it isn't done (I believe)
-- Love, shendaras

jrandom authored 20 years ago and zzz committed 20 years ago

pmd pointed out a few unnecessary things (well, a lot more than just this, but these are the ones i'm fixin ;)

aum authored 20 years ago and zzz committed 20 years ago

to True, will prevent the hostname lookup. This gives
the caller the option of passing in a physical destination
base64, instead of being limited to known hosts.

aum authored 20 years ago and zzz committed 20 years ago

files src/i2p/*Server.py, which are derived from the Python
standard library counterparts, and therefore inherit the Python license.

aum authored 20 years ago and zzz committed 20 years ago

and have been hacked to work with sunshine's I2P SAM Socket module.

jrandom authored 20 years ago and zzz committed 20 years ago

(0.3.4 and not 0.3.3.1 since its got some major revamps)
to be released later today.  dont upgrade until the release announcement comes out

jrandom authored 20 years ago and zzz committed 20 years ago

logging

jrandom authored 20 years ago and zzz committed 20 years ago

avoid the race that could corrupt local transfers by using a single thread to receive notifications of message availability (and in turn fetch that data)
the old way fired off a new (very short lived) thread for each message received, and if two happened really really quickly, they'd both lock on the mutex and the order would be undefined
this avoids that.  thanks to oOo et al for pestering me and sending in logs :)

jrandom authored 20 years ago and zzz committed 20 years ago

* drop the outbound message as soon as it expires rather than transferring an expired message
* drop hard any outbound message that takes us over 5 seconds to process (if we have a 5s message processing time, we do no one any good)
* don't try to resend (only useful when dealing with multiple transports - aka insufficiently tested code)
* don't republish netDb messages as often