Commit Graph

9 Commits

Author SHA1 Message Date
Brian Warner
1863aee0aa switch to using RemoteException instead of 'wrapped' RemoteReferences. Should fix #653, the rref-EQ problem 2009-05-21 17:46:32 -07:00
Brian Warner
c9803d5217 switch all foolscap imports to use foolscap.api or foolscap.logging 2009-05-21 17:38:23 -07:00
Brian Warner
0a59991ce6 various: use util.log.err instead of twisted.log.err, so we get both Incidents and trial-test-flunking 2008-09-20 10:35:45 -07:00
Zooko O'Whielacronx
78829dcf08 key_generator: make default key size be a constructor argument instead of a class variable, pass default key size of 522 (the smallest that we can do) in unit tests to make them faster 2008-04-22 12:28:18 -07:00
robk-tahoe
8620c7271d key_generator: fix edge case found on windows
the windows (cygwin) buildslave has been failing the key generator test

it turns out that the time check on whether to refill the pool, and the
reactor, are interacting such that when the maybe_refill_pool call posted
on the reactor fires, the test on whether to fill the pool fails.

this adds a loop in the failure case to retry each 1s until it is time
to refill the pool, thus mitigating this timing accuracy problem on
windows.
2008-04-10 14:27:35 -07:00
robk-tahoe
30eaaa7862 key_generator: fix timing, make tests more robust
previously there was an edge case in the timing of expected behaviour
of the key_generator (w.r.t. the refresh delay and twisted/foolscap
delivery).  if it took >6s for a key to be generated, then it was 
possible for the pool refresh delay to transpire _during_ the 
synchronous creation of a key in remote_get_rsa_key_pair.  this could
lead to the timer elapsing during key creation and hence the pool
being refilled before control returned to the client.

this change ensures that the time window from a get key request
until the key gen reactor blocks to refill the pool is the time
since a request was answered, not since a request was asked.
this causes the behaviour to match expectations, as embodied in
test_keygen, even if the delay window is dropped to 0.1s
2008-04-03 18:43:46 -07:00
robk-tahoe
1ae2c39862 key_generator: service related cleanups, incorporation into system test
this cleans up KeyGenerator to be a service (a subservice of the
KeyGeneratorService as instantiated by the key-generator.tac app)
this means that the timer which replenishes the keypool will be
shutdown cleanly when the service is stopped.

adds checks on the key_generator service and client into the system
test 'test_mutable' such that one of the nodes (clients[3]) uses
the key_generator service, and checks that mutable file creation
in that node, via a variety of means, are all consuming keys from
the key_generator.
2008-04-03 15:57:07 -07:00
robk-tahoe
ccda06b061 key_generator: added a unit test
implemented a unit test of basic KeyGenService functionality,
fixed a bug in the timing of pool refreshes
2008-04-03 13:01:43 -07:00
robk-tahoe
5578559b85 added offloaded key generation
this adds a new service to pre-generate RSA key pairs.  This allows
the expensive (i.e. slow) key generation to be placed into a process
outside the node, so that the node's reactor will not block when it
needs a key pair, but instead can retrieve them from a pool of already
generated key pairs in the key-generator service.

it adds a tahoe create-key-generator command which initialises an 
empty dir with a tahoe-key-generator.tac file which can then be run
via twistd.  it stashes its .pem and portnum for furl stability and
writes the furl of the key gen service to key_generator.furl, also
printing it to stdout.

by placing a key_generator.furl file into the nodes config directory
(e.g. ~/.tahoe) a node will attempt to connect to such a service, and
will use that when creating mutable files (i.e. directories) whenever
possible.  if the keygen service is unavailable, it will perform the
key generation locally instead, as before.
2008-04-01 18:45:13 -07:00