[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [freehaven-dev] meeting sunday, 2pm
On Sat, 1 Apr 2000, Roger R Dingledine wrote:
> a) technical overview of the entire project, including details, for
> rivest if he shows (yes, that's right, he's planning to go to our
> weekly freehaven meeting this week. be prepared to talk about your
> part of the project.)
I'm trying to figure out the best way to organize the presentation of the
communications module. Here's what I have so far; comments/corrections
appreciated. Imagine that I'm presenting it exactly as you read here.
Free Haven Communications Module
1) What it is, what it looks like :
The Communications Module is responsible for packaging traffic
between haven nodes. It runs as its own process on a servnet node, where
it communicates with a separate haven process. The Module is our interface
between the haven and the mix-nets we want to use.
2) Interacts with :
Incoming haven messages are polled, queued, and processed by the
Communications Module. Right now, we will check to see whether a file
exists in the directory the communications module runs in. Later, we will
support checking incoming mail, and possibly accepting connections from
Outgoing messages are passed to the Communications Module over a
socket from the Haven Module. They are then formatted / processed for
a mix-net and sent. Currently, we use the Mixmaster 2.9b client as our
formatting engine; the extent of the Communications Module is to
invoke the correct command line.
Every servnet node is identified by a unique public key. The Haven
Module is responsible for addressing a message by use of this public key.
The Communications Module is responsible for knowing the "best way" to
reach the node identified by that public key. This information is stored
in a GDBM database which is maintained on a disk accessible to the
Communications Module process.
3) Requirements :
* Deliver outgoing messages via anonymous channel to recipient.
* Poll for incoming messages.
* Queue incoming messages.
* Store information on how to reach each servnet node.
4) Events and Control Flow :
The process is started by invoking it with a listening port.
Control starts in main(), and then passes to initialize_nodedb().
The initialize_nodedb() does what it sounds like.
Then control is on to handle_haven(). The handle_haven() function
opens a socket and looks for a haven process. If it finds one,
then it goes into an event loop, waiting for messages.
Currently supported events are "broadcast" and "send" messages.
"send" refers to sending a message to a single servnet node,
while "broadcast" refers to sending a message to all known servnet
The communications module determines than an event has happened
by noticing that there is data coming across the socket from
the haven process. It determines what type of event has occurred
by parsing the data using Roger's tags parser.
In the case of a "send" event, the communications module saves the
contents of the message to a file on disk, creates
the appropriate command line for the Mixmaster process, then
invokes mixmaster. In order to "broadcast", we simply repeat
"send" for each and every servnet node in our database.
That seems about right. What am I missing?