[tor-commits] [flashproxy/rtmfp] Remove outdated information from README.

[dcf at torproject.org]

commit 15a659481601670a8081bec25e21686beb927138
Author: David Fifield <david at bamsoftware.com>
Date:   Sat Jun 11 12:26:53 2011 -0700

    Remove outdated information from README.
---
 README |   52 +++++++++++++---------------------------------------
 1 files changed, 13 insertions(+), 39 deletions(-)

diff --git a/README b/README
index 8597a96..ff12174 100644
--- a/README
+++ b/README
@@ -5,24 +5,12 @@ Adobe Flash proxy running on another computer. The Flash proxy can be
 run just by opening a web page in a computer that has Flash Player
 installed.
 
-This RTMFP version leverages the NAT-punching capabilities of Adobe's
-Cirrus server, making it possible for clients behind a NAT to still
-get access to Tor. The big operational difference between this version
-and the swfcat version is that now the client must maintain a rtmfpcat
-running in client mode open in his/her browser. The client's rtmfpcat
-talks to the rtmfpcat proxy running on another computer (location uncertain)
-via the UDP-based RTMFP to funnel data to a Tor relay/bridge.
-
 There are five main parts. Our terminology for each part is in quotes.
 1. The Tor "client," running on someone's localhost.
-2. A "connector," which waits for connections from the client's rtmfpcat and
+2. A "connector," which waits for connections from the Flash proxy and
    the Tor client, and joins them together.
 3. A Flash "proxy," running in someone's web browser. This piece is
-   called rtmfpcat (totally ripped off of swfcat) because it is like a
-   netcat implemented in Flash. The rtmfpcat exists on both the local
-   and remote ends since it's the easiest way to take advantage of RTMFP.
-   We could get rid of the client-side rtmfpcat by making the connector
-   speak RTMFP, but that's too much work for now. 
+   called swfcat because it is like a netcat implemented in Flash.
 4. A "facilitator," a pseudo-HTTP server that keeps a list of clients
    that want a connection, and hands them out to proxies.
 5. A Tor "relay," which is just a normal Tor relay except that its host
@@ -46,40 +34,34 @@ variable CIRRUS_KEY so it can be found by Makefile.
 
 To build, run
 	$ make
-Copy the resulting rtmfpcat.swf file to a web server.
+Copy the resulting swfcat.swf file to a web server.
 
 On the computer that will be the facilitator, run
 	sudo ./crossdomaind.py
 	./facilitator.py
 crossdomaind.py needs to be run on any server that will accept
 connections from a Flash proxy. It serves a chunk of data on port 843.
-The facilitator runs on port 9002 by default. Note that this is a different
-facilitator script than the swfcat one, since this facilitator needs to
-deal with Cirrus client IDs instead of ip:port tuples.
+The facilitator runs on port 9002 by default.
 
 The client needs to be running a version of Tor that supports the
 Socks4Proxy configuration. This means version 0.2.2.1-alpha or
 later--not the current stable release.
 
 On the client, run
-	./connector.py
-This is a modified form of the swfcat connector.py that has different
-defaults, equivalent to passing 127.0.0.1:9001 for [LOCAL][:PORT] and
-127.0.0.1:3333 [REMOTE][:PORT] to the swfcat connector.
-
-Also on the client, open up the browser to rtmfpcat.swf. Passing no
+	./connector.py 127.0.0.1:9001 127.0.0.1:9002
+Also on the client, open up the browser to swfcat.swf. Passing no
 arguments should give you good defaults (expects the facilitator running
-on Nate's server). rtmfpcat will connect to the Cirrus server to
+on Nate's server). swfcat will connect to the Cirrus server to
 obtain a client ID which it then registers with the facilitator.
 
-In a browser somewhere, open rtmfpcat.swf and pass the "?proxy=true" query
-string, telling it to operate in proxy mode.
-	http://www.example.com/rtmfpcat.swf?proxy=true
-This rtmfpcat will also connect to the Cirrus server to obtain a client ID,
+In a browser somewhere, open swfcat.swf and pass parameters telling it
+which facilitator to use and to operate in proxy mode.
+	http://www.example.com/swfcat.swf?proxy=true&facilitator=<FACILITATOR_IP>:9002&debug=1
+This swfcat will also connect to the Cirrus server to obtain a client ID,
 and then it will ping the facilitator to check if there are any registered
 client IDs. If there is one, it will open a RTMFP connection (coordinated
 by the Cirrus server) to the client and an additional connection to a 
-hardcoded Tor relay (David's bridge, nicknamed eRYaZuvY02FpExln).
+Tor relay.
 
 Back on the client, start Tor with the following configuration:
 	UseBridges 1
@@ -92,7 +74,7 @@ If you see messages like
 try deleting the files in ~/.tor or /var/lib/tor.
 
 You will be able to see byte counts flowing in both browsers displaying
-rtmfpcat.swf (client and proxy), and eventually be able to build a circuit.
+swfcat.swf (client and proxy), and eventually be able to build a circuit.
 
 == Rationale
 
@@ -111,14 +93,6 @@ Clients register with the facilitator by sending an HTTP message:
 	POST / HTTP/1.0\r\n
 	\r\n
 	client=<CIRRUS-CLIENT-ID>
-
-The <CIRRUS-CLIENT-ID> is returned by Adobe's developer Cirrus server
-as soon as the rtfmpcat can connect to it. Each rtmfpcat needs to connect
-to a server like this to get one of these client IDs, since the Cirrus
-server uses these to coordinate RTMFP connections (including NAT punching).
-The need to communicate with a Cirrus server in addition to a facilitator is
-one of the major weaknesses of this design.
-
 The Flash proxy also gets a client address over HTTP:
 	GET / HTTP/1.0\r\n
 	\r\n