Peer to peer

Peer to peer differs from Client Server in the way that each peer is both client and an server at the same time.

Also known as P2P.

DTN2 is the reference implementation of the Delay Tolerant Networking Research Group [1]. It is a daemon which allows efficient transmission of messages over a peer-to-peer network of unreliable nodes. It features an embedded Tcl interpreter which enables a console interface and scripting of functions. Works on Unix, Mac and Windows (via Cygwin).

Zarutian 2005-07-25-15:02 Okay I am going to make a simple peer to peer system in Tcl.

First of the spec:

'Functional specfication of simpleP2P'

Overview:

simpleP2P is a little program that demonstrates how to make a simple peer to peer system in Tcl
'This spec is not, by any stretch of the imagination, complete.' All of the wording will need to be revised several times before it is finalized.

Scenarios:

  Scenario 1: Raoul
   Raoul is a programmer relativitely new to Tcl and wants to try something
   kewl with Tcl. Raoul doesn't want to install a big runtime on his machine,
   so he gets the tclkit for his platform of choice. He then downloads
   simpleP2P.kit to the same folder (or if you prefer: directory) as his
   tclkit executable is in. He drags the simpleP2P.kit over his tclkit
   executable and therefore starts the simpleP2P application. Up pops the
   console and a window showing him the built-in command manual for the
   application. He enters the command "listen 8050". Raoul IMs his buddy
   asking him to get tclkit and simpleP2P.kit and enter the command
   "connect raoul.cjb.net 8050"

Non-Goals:

  * we are not going to use XML to format messages between peers
  * simpleP2P wont support connecting through a proxy.
  * simpleP2P wont have a file search capability

... arrh I don't know how to write functional specs! But I sure won't give up. It will be done eventually -Zarutian

When it comes to functional specs, I suggest that first you start with your requirements. What to you want it to do? What do you want it not to do?

Second, what policies do you want it to implement. (Using a queue is a policy; using a linked list is a mechanism. For functional specs, stay away from mechanisms.)

Third, think about tests. What test could you perform that would tell you if the implementation is performing correctly? (If you can't think of how to test it, then how can you tell if it's working or not?)

Fourth, this one a step that I invented myself (though I doubt it's completely original). Imagine an implementation of the requirements that meets the stated requirements, but is absurd in some way. (This is a mechanism for requirements solicitation that I had to use when an organization wanted something implemented, but they said that they had no requirements.) For example, what if whatever you implemented limited you to messages of 80 chars in length? What if you had to log in every time you wanted to send a message? What if you had to enter the name of the peer every time you wanted to send a message? You might not have thought to specify these, but they are probably requirements you have that you just didn't think to write down.

At Honeywell (at least in the now-dim past), they used to say that, Quality is conformance to written requirements. (It's kind of like mathematical logic, where you say that, Something is true if it cannot be proven to be false.) If you can have an implementation of your functional requirements that in fact does not function acceptably, then you forgot to specify some requirements.

Lars H: I don't know what kind of logic that is, but it's definitely not mathematical. Optimistic logic, perhaps? The mathematical definition of "true" is that

: A formula is true (for a particular model) if it is satisfied for every assignment of values from the model domain to the free variables in the formula.

MJ - Also note that for a sufficiently strong axiomatic system, there are statements that cannot be proven to be false, while still being false. For the rigorous version of this statement see Gödel's incompleteness theorems [2].

Zarutian 29. nóvember 2007: I have given this effort up (for now at least) because I have found http://randpeer.com/

to be more interesting and more in lieu of what I have in mind.

See Also edit