[noctool-cvs] CVS web

[imattsson]

Update of /project/noctool/cvsroot/web
In directory clnet:/tmp/cvs-serv6194

Modified Files:
	hacking.html 
Log Message:
IM

Added some mumblings about the network layer.


--- /project/noctool/cvsroot/web/hacking.html	2008/05/27 16:34:03	1.4
+++ /project/noctool/cvsroot/web/hacking.html	2008/08/27 06:12:27	1.5
@@ -71,7 +71,7 @@
 
 <h2>Graphs</h2>
 The graph classes come in several sub-classes, depending on how they
-transfer data fromshorter-term storage to longer-term storage. Each
+transfer data from shorter-term storage to longer-term storage. Each
 storage class keeps 300 records and every 12th value added to a
 storage-class initiates a transfer of data to longer-term storage.
 <p>
@@ -129,8 +129,55 @@
 
 The mapping from equipment class to default monitors is done in <tt>default-settings.lisp</tt>.
 
+<h2>Network layer</h2>
+
+The network layer is implemented as a reader/parser/protocol
+dispatcher combo, where the reader is aware of the rough syntactic
+rules and hands over a complete read to the parser. It is done this
+way so incomplete syntactic units can be sent across the network, to
+be completed in a following transmission.
+
+The parser is, for all intents and purposes, CL:READ-FROM-STRING (at
+the moment), though it binds *READ-EVAL* and *READ-BASE*.
+
+The resulting list data structure (whose rough structure is:
+<blockquote>(message <i>protocol-data</i> <i>digest</i>)</blockquote>
+
+The protocol-data is extracted and handed over to the protocl handler
+loop, where different things happen depending on the state of the
+connection.
+
+There are three recognised states for any given connection, they can
+be initial, sent-validation or validated. The state is kept in the
+STATE slot of the connection class.
+
+When a connection is opened, the opening party will send an IAM
+protocol message (that looks roughly like "(iam sender reciever
+20080401T131415)") and sent its own state as sent-validation.
+
+Any incoming connection will be created in the initial state. The main
+difference between the initial and sent-validation states is how they
+react ti an IAM protocol message. In the initial state, this triggers
+teh sending of an IAM message before moving to the validated state, in
+the sent-validation case it does not.
+
+The IAM message is used to tie a connection to a specific peer (as
+configured). Each peer-to-peer connection has one or two secrets
+(either identical or different shared secret(s)), this secret is used
+for a HMAC-SHA1 digest of the protocol-data. The amount of time an
+IAM  message can be outstanding is controlled by VALIDATE-TIMESTRING.
+
+In the validated state, protocol messages are dispatched by looking up
+the protocol message identifier in a hash table (called
+*HANDLER-MAP*). The easiest way to define a new handler is by the
+DEFHANDLER macro, where the lambda-list should match the protocol
+message, in-so-far as the first symbol listed will be used for
+dispatching. Also note that DEFHANDLER will add a CONN argument to the
+lambda list that will be the connection that caused the protocol
+handler to be called during execution.
+
 <div class="footer">
- Last updated on $Id: hacking.html,v 1.4 2008/05/27 16:34:03 imattsson Exp $, by $Author: imattsson $
+ Last updated on $Id: hacking.html,v 1.5 2008/08/27 06:12:27 imattsson Exp $, by $Author: imattsson $
 </div>
 </body>
 </html>