- Jul 30, 2004
-
- Jul 29, 2004
-
-
-
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 :)
-
* 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
-
- Jul 28, 2004
-
- Jul 27, 2004
-
-
* removed SourceRouteBlock & SourceRouteReplyMessage, as they're a redundant concept that 1) takes up bandwidth 2) takes up CPU 3) smell funny. now the TunnelCreateMessage includes a replyTag, replyKey, replyTunnel, and replyGateway that they garlic encrypt their ACK/NACK through and with. * tunnelCreateMessage doesn't need a seperate ACK - either we get a TunnelCreateStatusMessage back or we don't. * message structure mods for unique tunnel ID per hop (though currently all hops have the same tunnel ID)
-
(making a searchReply message ~100 bytes, down from ~30KB, and the lookup message ~64 bytes, down from ~10KB) * when we get the netDb searchReply or lookup message referencing someone we don't know, we fire off a lookup for them * reduced some excessive padding * dropped the DbSearchReplyMessageHandler, since it shouldn't be used (all search replies should be handled by a MessageSelector built by the original search message) * removed some oddball constructors from the SendMessageDirectJob and SendTunnelMessageJob (always must specify a timeout) * refactored SendTunnelMessageJob main handler method into smaller logical methods
-