P2P编程

开发平台：
Java

Readme.txt：源码内容
							******************************************************************
*			Secure P2P framework (SePP) (v0.2.1)       			           *
******************************************************************
SePP is a secure P2P framework which allows application 
developer to create secure distributed components in a
simple manner. The framework provides not only the typical
management and communication features but also the relevant
security features (e.g.: digital signatures, encryption, 
authentication, ...) using state-of-the-art cryptographic 
primitives and algorithms. The secure P2P framework also 
copes with security issues right from the start of the P2P
network, allowing only legitimate peers to take part in the
network through a secured join process. Another very relevant
security feature of this framework is the availability of 
secure routing algorithms. One can choose between different
routing algorithms depending on the use case of the developed
application. 
The whole secure P2P framework has been developed with a 
coherent and comprehensive security concept in mind which allows
the application developer and network designer to exactly specify
the security requirements of the application and network. Thus,
all the potential peers must comply to this requirements to take
part in this network.
------------------------------------------------------------------
In the root directory of this package there exist two simple 
scripts which can be used to start a simple demo application.
The demo application features a chat client with a simple GUI.
There exists a version for Windows- and Linux-based systems.
The application is started by executing this script and providing
a number as parameter. This number relates to the peer 
configuration which should be used to start this client. For 
simplicity reasons the peers are named "peerX" where the X denotes
the number of the peer. Therefore, the peer1.config in the "res"
directory is the configuration file for peer1 and so on. Therefore,
for starting peer1 one would execute the following command.
start_chat 1
Currently, there are 6 configuration files in the directory which 
means that only 6 different peers can be started now. The current
configuration specifies that all peers are started on the local 
host and listen on different ports. If one wants to run them on
different hosts the according configuration files must be adjusted.
There is also a mechanism implemented to find peers in the local
network but it has not been tested very seriously. Therefore, it
is recommended to use this framework in the current version only
with peers specified in their associated configurations and with
the parameter "RunLocal" set to true. In upcoming versions this 
mechanism will be available. 
In this version also support for storing messages sent and 
received at the peers and errors produced during processing of 
these messages in a database has been added. In the config file
there are some parameters for configuring the database support.
<UseDatabase> - True or false for storing data in the database.
<DatabaseURI> - Specifies the URI of the database as used by JDBC
<DatabaseUser> - User name for the database access
<DatabasePassword> - Password for the specified database user
If you have any other questions either consult the included Java
documentation, visit the project home page and its WIKI on 
http://sourceforge.net/projects/securep2p/ or 
contact me through securep2p@iaik.tugraz.at
Good luck and much fun,
Stefan Kraxberger 
Institute of Applied Information Processing
Graz University of Technologoy, Graz, Austria
------------------------------------------------------------------
														Change log
------------------------------------------------------------------
v0.2.1 (July 2009)
	- Modified internal structure of the XML, logging and security 
	  function integration in order to have one code for Java SE 
	  and ME. Now only the implementation class must be specified 
	  in the configuration and the approriate library must be 
	  available from the class path. 
	- Added UDP support to the IO subsystem. Now it is also possible  
	  to send messages using datagrams. But I the route error 
	  mechanism must be adapted since there is no explicit 
	  notification if sending a message to a neighbor failed (UDP
	  is unreliable). Thus, the neighborhood mechanism, which checks
	  the availability of neighbors and tries to find new neighbors
	  must now implicitly inform the routing algorithm that a specific
	  neighbor isn't available anymore. The routing algorithm can than
	  perform the necessary tasks, depending on the algorithm usage.
	  Will be updated in the next release. 
v0.2.0 (April 2009)
	- Modified the underlying IO subsystem to a thread based 
	  architecture. The new subsystem has also be designed in a 
	  modular way which allows for simple exchange of the used
	  implementation.
	- The AODV and OLSR routing algorithms have been tested and 
	  are working as expected. Some minor issues may arise in OLSR
	  since we were not able to test it with massive amounts of 
	  nodes.
v0.1.3 (February 2009)
	- AriadneRouting has been integrated and tested. Now it should 
	  work almost properly. Some modifications must still be made
	  because no improvements to Ariadne have been implemented so
	  far.
	- The route error handling and invocation of DSR have been 
	  modified since some problems have been reported. Now route
	  error should work as described in the RFC. At this point none
	  of the improvements for DSR have been implemented but are now
	  scheduled.
	- Modified the neighbor algorithm and made some simplifications
	  of the whole communication code.
v0.1.2 (November 2008)
	-	Modified the routing algorithm DSR to be compliant with the 
	  original version and support route replies from intermediate
	  hosts to allow for faster route discovery.
	- Modifications of the route cache instantiation to allow 
	  different kinds of caching strategies and architectures. 
	  Currently the simplest one, the Path Cache, is implemented.
	- Removed some bugs in the message processing mechanism.
v0.1.1 (September 2008)
	- Modified the process of discovering new peers. Previously it 
	  wasn't possible that peers become neighbors which havn't been 
	  specified as neighbors in the configuration mutually. Now 
	  peers must not specify each other as neighbors to become 
	  neighbors during runtime.
	- Some problems with the reachability of peers have been solved. 
	  Still, the process isn't completely reliable yet. 
	- Modified the DSR routing algorithm, due to some problems with
	  creating routes from already existing routes in intermediate
	  peers.   

						