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@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev