NOTES 2.3 KB

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485868788899091
  1. Nick's goals:
  2. go from "cautiously optimistic on the approach" to "workable" or
  3. "unworkable".
  4. come up with "my favorite tests" and verify that they're
  5. implementable by me
  6. The main criterion:
  7. * "can a general person who is not familiar with the system write
  8. a useful test?"
  9. * "can a person with zero knowledge of the system run the
  10. resulting tests?"
  11. Portability notes:
  12. supported Debian & Fedora releases
  13. XP & later
  14. 10.5 & later
  15. all other unixes: support on demand
  16. marginal:
  17. Win2k
  18. OS X 10.4
  19. Tests X Networks:
  20. functional tests:
  21. does the network bootstrap?
  22. can I reach foo.com?
  23. can I reach a hidden service?
  24. can I reach the client's DNS "resolver"?
  25. can I use the server's DNS client?
  26. no crashes are observed under any test inputs?
  27. map address functionality works?
  28. do all of socks 4, 4a, 5 work?
  29. (w/ two versions of tor?)
  30. (w/ tor running on three platforms?)
  31. "run the fast machine stuff"
  32. "pick up after a test failed"
  33. "run a test by name"
  34. "run tests in parallel"
  35. bridge-related stuff:
  36. run a network with bridges on it
  37. make sure that clients can use bridges
  38. make sure that bridges announce themselves to a bridge authority
  39. testable invariants & surprises:
  40. all circuits get built "correctly"
  41. almost always, keep some clean circuits connected to useful
  42. exit nodes
  43. tricky stuff:
  44. unusually configured clients
  45. (i.e. options for specifying what nodes tor will use for
  46. building paths)
  47. stream isolation design
  48. load tests
  49. (short, medium, and long-term)
  50. configuration transitions
  51. familialy related nodes should not be used in the same circuit
  52. demonstrate that, for all inputs, no crashes occur
  53. assertions made in the man page & specs:
  54. bandwidth limiting works
  55. bandwidth accounting works
  56. clients respect advertised exit policies
  57. advertised exit policies are enforced
  58. Information flows:
  59. what networks are statically feasible for the given tests?
  60. are there ever flows from the tests to the networks?
  61. even if there are: aren't they just "requirements"
  62. query the network and its nodes for config data
  63. Implementation questions:
  64. Twisted?
  65. something Erlang-ish?
  66. (neither of us is thrilled with expect...)