commit 6df54da6f97d3c3127f23b066f1596e9ff62558e Author: Karsten Loesing karsten.loesing@gmx.net Date: Tue Sep 24 15:10:04 2013 +0200
Add Sathya's comments from tor-dev@. --- 2013/torperf2/torperf2.tex | 39 ++++++++++++++++++++++++++++++--------- 1 file changed, 30 insertions(+), 9 deletions(-)
diff --git a/2013/torperf2/torperf2.tex b/2013/torperf2/torperf2.tex index d67bd62..b8f2e71 100644 --- a/2013/torperf2/torperf2.tex +++ b/2013/torperf2/torperf2.tex @@ -121,13 +121,27 @@ What's not easily possible with this approach is to configure client and server to run on different hosts. Is there an experiment where this might be useful?
-\subsubsection{Experiment extensibility considerations} - -It should be easy for a user to implement or install an experiment that isn't -bundled with the core distribution. Ideally, installing an experiment should be as -simple as unzipping a folder or config file into an experiments folder. -Optimally, the Torperf service would detect the new experiment and schedule -it as soon as practical without additional user intervention. +% Commented out Kevin's text on 2013-09-24: +% \subsubsection{Experiment extensibility considerations} +% +% It should be easy for a user to implement or install an experiment that isn't +% bundled with the core distribution. Ideally, installing an experiment should be as +% simple as unzipping a folder or config file into an experiments folder. +% Optimally, the Torperf service would detect the new experiment and schedule +% it as soon as practical without additional user intervention. +% Sathya on tor-dev@: +% "I don't understand how this will work when users just apt-get install +% torperf. Ideally if someone writes a good experiment, they should send +% the patches upstream and get it merged, and then we update torperf to +% include those tests and then the users just update torperf with their +% package managers." +% Karsten on tor-dev@: +% "I don't feel strongly. I'd prefer a design that makes it easy to add +% new experiments, but I'm fine with an approach that requires merging +% patches. We can always add the functionality to drop something in a +% directory and make Torperf magically detect and run the new experiment, +% but that can happen later. Maybe we shouldn't let that distract us from +% getting the first version done. I commented out this section."
% Commented out Kevin's text by Karsten on 2013-09-18: % For implementing, this will require a clearly defined interface for developers @@ -179,6 +193,12 @@ signature of new tor versions as they are released. The user could specify if they plan to test stable, beta or alpha versions of tor with their Torperf instance.
+This requirement should be implemented in three phases: 1) Torperf uses +the default tor binary that comes with the operating system; 2) Torperf +accepts the path to a tor binary that was previously built by the user; +3) Torperf accepts that path to a Git tag or tor source directory and +downloads, verifies, and builds a tor binary itself. + \subsubsection{User-defined third-party software version or binary}
Similar to the previous requirement, it should be easy to specify custom @@ -217,7 +237,9 @@ requests.% Deciding which data to store should be the responsibility of whoever designs a Torperf experiment, though formats should be somewhat uniform between experiments. -A possible results data format could be based on JSON,% +Torperf should store its results in a format that is widely used and +already has libraries (like JSON), so that other applications can use +the results and build on it.% \footnote{In particular, we could use a de-facto standard like the HAR (HTTP Archive) format to store measurements results. Advantages are that such a format is widely used and that there are a lot @@ -227,7 +249,6 @@ not relevant to us, and that we'd have to add tor-specific data fields to the format which wouldn't be processed by existing tools. Note that we could use such a format only for request data, not for tor-specific data like building circuits and attaching streams.} -but other data formats are plausible, too.
\subsubsection{Results web interface}