Re: [freehaven-dev] meeting sunday, 2pm

[dmolnar@belegost.mit.edu]

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
outside. 

        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
	nodes.

	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?

Thanks 
-David