[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-commits] [flashproxy/rtmfp] Remove outdated information from README.
commit 15a659481601670a8081bec25e21686beb927138
Author: David Fifield <david@xxxxxxxxxxxxxxx>
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
_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits