Hi everyone,

As I stated in my last status report, I promised to work on server-to-server 
communication in preparation for a beta test. Quite a bit of work was done in 
this area, with the result that the server-server protocols are now working as 
intended and fairly reliably. The changes include:

* Ability to bind to a specific IPv4 address. This is useful not only in 
servers with multiple interfaces, but allows two instances of OnioNS-server to 
run simultaniously on localhost, which is great for testing and debugging.
* Improved server-side logging and diagnostic information. Each network session 
has it's own identification number, which makes it easy to keep track of events 
and conversations.
* Rewrote the networking code responsible for retransmitting information such 
as new Records. The servers now correctly sends Records to subscribers.
* A Mirror server now reestablishes the network connection with a Quorum server 
if the Quorum server drops from the network.
* Many bug fixes, addressing numerous issues with crashes, networking issues, 
and serialization faults.

With these changes, the OnioNS project is in a pretty good state. Here's an 
overview of the system's order of operations:

1) A single Quorum server starts up and listens on a specific IP and port. It's 
a TCP server and waits for JSON-encoded messages.
2) A Mirror server starts up, connects with and subscribes to the Quorum server.
3) A hidden service operator generates a claim on a domain name (say 
"example.tor") and optionally some subdomains. This claim is represented in the 
Record data structure.
4) The operator sends the Record over a Tor circuit to the Quorum server, who 
inspects it, caches it, and sends it to all subscribers, which is the single 
Mirror node.
5) The Mirror inspects the Record, caches it, and sends it to all subscribers, 
but here it doesn't have any.
6) A client starts up the Tor Browser with the OnioNS software installed. This 
means that the starting of the Tor Browser also triggers the launching of the 
OnioNS software: a binary and a Python script.
7) The user types in "example.tor". Their Python script detects the pseudo-TLD 
and performs a query lookup to the Mirror node, who replies with the Record.
8) The OnioNS-client software inspects the Record, extracts the hidden service 
address, and passes the address back to the Stem script.
9) The Stem script rewrites the original stream request from step 7 to this HS 
address and tells Tor to attach the stream to some circuit.
10) Tor attaches the stream with the effect that the hidden service loads in 
the Tor Browser.

All of these pieces are now in place and generally work as intended without 
requiring any user intervention. The step of separating the responsibility into 
two different servers is now behind me, which when coupled with the working 
subscriber-based server-server communication, gives me many options to move 
forward towards a distributed system. I have a couple of annoyance-level bugs 
to fix but a prototype is very near. I will be shortly resume building packages 
and will currently be supporting Ubuntu, Mint, Debian, and Fedora on i386, 
amd64, and armhf.

As a final note, a quick thanks to George for the well-written 
commit-reveal-consensus proposal. As he stated in his introduction, I certainly 
need that in order to integrate OnioNS with the Tor network.

Jesse V.


Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Reply via email to