[ZODB-Dev] Number of clients connecting to a ZEO Server

Jim Fulton jim@digicool.com
Tue, 22 May 2001 07:03:45 -0400


Chris Withers wrote:
> 
> Glad to see security of ZEO connections is getting an airing, it'd be very
> useful :-)

Note that here was discussion about this a few weeks ago.
It talked about the difference between controlling access to the 
server (as a whole) at the connection level and controlling
access to parts of the database. The later can be broken into
authentication and authorization. Authorization is really hard, 
since, at least for Zope, the security lives way above the
database level.  We discussed (hinted) how a much lower level
(than Zope's) security model might be implemented for ZODB.

> For the same project, can anyone tell me how many ZEO clients you can usefully
> connect to one storage server?

I don't think anybody has tried to push/test this limit.  The limit will certainly
depend on usage (read/write) patterns.
 
> Also, I remember whispers of a distributed storage server a while back... would
> this mean there could be serveral storage servers for the same ZODB increasing
> the number of ZEO clients that could connect?

Yes. For read-intensive access, it should also be possible (with some minor
changes to storage servers) to arrange storage servers hierarchically, where
some storage servers are storage clients.
 
> Finally, what's the minimum I need, in terms of libraries, etc, to open a ZEO
> connection to a storage server so I can start playing with objects in the ZODB?

Sadly, you need a little more than you should. This includes:

  - ZEO

  - ZODB

  - ExtensionClass

  - Python 2.1 or Zope's cPickle and asyncore

  - zdaemon, zLOG, ThreadedAsync, Persistence

and, if you want to be able to do Undo the way that Zop does, 
you'll beed:

  - App.Undo (for the Prefix class, waaaa).

> PS: This is all looking towards building a fat client for Zope, based on Python
> and using a ZEO connection to get hold of the objects.

I fear that the security model is going to be the biggest challenge
unless you are willing to totally trust the clients.  If you aren't, then
you might be bertter off with a xmlrpc or SOAP-based approach, however, then
you'd have a database consistency problem to deal with.


Jim

--
Jim Fulton           mailto:jim@digicool.com   Python Powered!        
Technical Director   (888) 344-4332            http://www.python.org  
Digital Creations    http://www.digicool.com   http://www.zope.org