These files are a subset of the python-2.7.2.tgz distribution from python.org. Changed files from PyMod-2.7.2 have been copied into the corresponding directories of this tree, replacing the original files in the distribution. Signed-off-by: daryl.mcdaniel@intel.com git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13197 6f19259b-4bc3-4df7-8a09-765794883524
		
			
				
	
	
		
			122 lines
		
	
	
		
			4.3 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
			
		
		
	
	
			122 lines
		
	
	
		
			4.3 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
Filesystem, RCS and CVS client and server classes
 | 
						|
=================================================
 | 
						|
 | 
						|
*** See the security warning at the end of this file! ***
 | 
						|
 | 
						|
This directory contains various modules and classes that support
 | 
						|
remote file system operations.
 | 
						|
 | 
						|
CVS stuff
 | 
						|
---------
 | 
						|
 | 
						|
rcvs			Script to put in your bin directory
 | 
						|
rcvs.py			Remote CVS client command line interface
 | 
						|
 | 
						|
cvslib.py		CVS admin files classes (used by rrcs)
 | 
						|
cvslock.py		CVS locking algorithms
 | 
						|
 | 
						|
RCS stuff
 | 
						|
---------
 | 
						|
 | 
						|
rrcs			Script to put in your bin directory
 | 
						|
rrcs.py			Remote RCS client command line interface
 | 
						|
 | 
						|
rcsclient.py		Return an RCSProxyClient instance
 | 
						|
			(has reasonable default server/port/directory)
 | 
						|
 | 
						|
RCSProxy.py		RCS proxy and server classes (on top of rcslib.py)
 | 
						|
 | 
						|
rcslib.py		Local-only RCS base class (affects stdout &
 | 
						|
			local work files)
 | 
						|
 | 
						|
FSProxy stuff
 | 
						|
-------------
 | 
						|
 | 
						|
sumtree.py		Old demo for FSProxy
 | 
						|
cmptree.py		First FSProxy client (used to sync from the Mac)
 | 
						|
FSProxy.py		Filesystem interface classes
 | 
						|
 | 
						|
Generic client/server stuff
 | 
						|
---------------------------
 | 
						|
 | 
						|
client.py		Client class
 | 
						|
server.py		Server class
 | 
						|
 | 
						|
security.py		Security mix-in class (not very secure I think)
 | 
						|
 | 
						|
Other generic stuff
 | 
						|
-------------------
 | 
						|
 | 
						|
cmdfw.py		CommandFrameWork class
 | 
						|
			(used by rcvs, should be used by rrcs as well)
 | 
						|
 | 
						|
 | 
						|
Client/Server operation
 | 
						|
-----------------------
 | 
						|
 | 
						|
The Client and Server classes implement a simple-minded RPC protocol,
 | 
						|
using Python's pickle module to transfer arguments, return values and
 | 
						|
exceptions with the most generality.  The Server class is instantiated
 | 
						|
with a port number on which it should listen for requests; the Client
 | 
						|
class is instantiated with a host name and a port number where it
 | 
						|
should connect to.  Once a client is connected, a TCP connection is
 | 
						|
maintained between client and server.
 | 
						|
 | 
						|
The Server class currently handles only one connection at a time;
 | 
						|
however it could be rewritten to allow various modes of operations,
 | 
						|
using multiple threads or processes or the select() system call as
 | 
						|
desired to serve multiple clients simultaneously (when using select(),
 | 
						|
still handling one request at a time).  This would not require
 | 
						|
rewriting of the Client class.  It may also be possible to adapt the
 | 
						|
code to use UDP instead of TCP, but then both classes will have to be
 | 
						|
rewritten (and unless extensive acknowlegements and request serial
 | 
						|
numbers are used, the server should handle duplicate requests, so its
 | 
						|
semantics should be idempotent -- shrudder).
 | 
						|
 | 
						|
Even though the FSProxy and RCSProxy modules define client classes,
 | 
						|
the client class is fully generic -- what methods it supports is
 | 
						|
determined entirely by the server.  The server class, however, must be
 | 
						|
derived from.  This is generally done as follows:
 | 
						|
 | 
						|
	from server import Server
 | 
						|
	from client import Client
 | 
						|
 | 
						|
	# Define a class that performs the operations locally
 | 
						|
	class MyClassLocal:
 | 
						|
		def __init__(self): ...
 | 
						|
		def _close(self): ...
 | 
						|
 | 
						|
	# Derive a server class using multiple inheritance
 | 
						|
	class MyClassServer(MyClassLocal, Server):
 | 
						|
		def __init__(self, address):
 | 
						|
			# Must initialize MyClassLocal as well as Server
 | 
						|
			MyClassLocal.__init__(self)
 | 
						|
			Server.__init__(self, address)
 | 
						|
		def _close(self):
 | 
						|
			Server._close()
 | 
						|
			MyClassLocal._close()
 | 
						|
 | 
						|
	# A dummy client class
 | 
						|
	class MyClassClient(Client): pass
 | 
						|
 | 
						|
Note that because MyClassLocal isn't used in the definition of
 | 
						|
MyClassClient, it would actually be better to place it in a separate
 | 
						|
module so the definition of MyClassLocal isn't executed when we only
 | 
						|
instantiate a client.
 | 
						|
 | 
						|
The modules client and server should probably be renamed to Client and
 | 
						|
Server in order to match the class names.
 | 
						|
 | 
						|
 | 
						|
*** Security warning: this version requires that you have a file
 | 
						|
$HOME/.python_keyfile at the server and client side containing two
 | 
						|
comma- separated numbers.  The security system at the moment makes no
 | 
						|
guarantees of actuallng being secure -- however it requires that the
 | 
						|
key file exists and contains the same numbers at both ends for this to
 | 
						|
work.  (You can specify an alternative keyfile in $PYTHON_KEYFILE).
 | 
						|
Have a look at the Security class in security.py for details;
 | 
						|
basically, if the key file contains (x, y), then the security server
 | 
						|
class chooses a random number z (the challenge) in the range
 | 
						|
10..100000 and the client must be able to produce pow(z, x, y)
 | 
						|
(i.e. z**x mod y).
 |