Re: [Cxtable-devel] RE:p2p, the next generation [small reply]

[Borne Goodman-M. <bm...@eg...>]

I am indeed not 100% clear on where cxtable's current implementation
exists within the space of my vision, which was developed out of
self-introspection, and a lot of experience, and an understanding (I
think) of the optimal mechanism for information sharing / communication.

I have always love the concept of having systems communicate with each
other over the network, in much the way that humans do in the physical
world.  I think that improvements can be made, technologically, to the
way we traditionally communicate, and this vision is the beginning down
that path for me (and whomever might like to come with me).

I do understand, basically, how the cxtable system currently works, from
a networking perspective, and I do feel there is a sizable amount of
re-work to be done to make the changes I suggested to it.  So much work
in fact, especially in the case of sticking in security, that it might
be faster to start from scratch, but this is not a certainty at this
point.  cxtable is a system that you developed from the ground up (with
some help here and there) and it is a fairly large derivation from the
way things work now, which is why I would understand if you aren't
interested in my ideas and would rather pursue your own.

It is rare that people can work together with common purpose / vision to
develop a great piece of software, and I find my ideas are usually a bit
lofty for a lot of people to consider reasonable, and they would rather
write something very particular (like a shared data space /
"grapevine").

I do believe, after a summary look at the "grapevine" project, that our
thoughts are a bit closer, than that of grapevine, though I think that
kind of capability could easily be put into the framework I have in
mind.

I shall respond to your other email, with more detailed answers to your
questions about my initial email, to better describe what my concepts of
a client / server / service truly represent and I will also try to give
some examples of it's usage to more easily put the components in their
correct context.

--bjgm

On Wed, 2002-01-02 at 15:51, Williams, David wrote:
> Larger one to follow, after I've better read through your thoughts...
> 
> This reply is mainly to ask a few questions, which might or might not be self-serving... 
> 
> Are you clear on where cxtable sits with relation to this vision?  In other words, do these visions come from self-introspection with relation to the internet itself, or with some digging about in my code, a mixture?
> 
> I ask this only to see whether you have come up with an assessment of how cxtable accomplishes p2p...  I also ask it because there is another project that is working toward peer-to-peer that I have been impressed with.... They are primarily looking to create a persistent file storage network across anonymous peer-to-peer...  It is grapevine.sourceforge.net...
> 
> I almost reticently point you at it, as Stephen and I are approaching two different goals, and I am unsure of whether or not his is closer to yours than mine... 
> 
> Primarily, I am wondering, what adaptation would be required, on my part...  I assume, in many ways, everything after the "line" in your message will explain that to me..so I will read it, and reply again...
> 
> Either way, your help has been valuable to me...  (Again... I hope that by pointing you toward Grapevine- a class act, I have not found you a new project to replace your participation in mine...  but Stephen, et al, of the Grapevine project are way deserving of help, as well..)
> 
> ~Dave
> 
> 
> 
> David Scott Williams
> Computer Associates
> Marketing Representative-Sales Call Center
> One Computer Associates Plaza 
> Islandia, New York  11749
> tel: +1 800-243-9462 ext. 73431
> tel: +1 631-342-3431 (Direct)
> fax: +1 631-342-5734
> wi...@ca...
> 
> 
> 
> 
> 
> 
> -----Original Message-----
> From: Borne Goodman-Mace [mailto:bm...@eg...]
> Sent: Wednesday, January 02, 2002 3:38 PM
> To: cxt...@li...
> Subject: [Cxtable-devel] p2p, the next generation.
> 
> 
> Greetings,
> 
> As I mentioned to you, my interest in the cxtable project is mainly due
> to my feelings about the proper direction for applications / knowledge
> sharing in the future, and that the next step is to create a system
> which is neither purely p2p nor purely client/server.
> 
> I have spent a bit of time in the last few days thinking about exactly
> what this system should look / act like, and would like to explain this,
> and do one of two things with this knowledge, based on your feelings.
> 
> 1) Change cxtable to adapt to a slightly different vision, which
> included the concepts I am going to present, at which point I will drop
> my work on OMInit.
> 
> 2) Continue to work om OMInit and evolve it to also support the concepts
> which I am going to present, and continue to give information /
> assistance on cxtable when possible.
> 
> The following concepts are rough, and certainly open to discussion /
> evolution, but I think are a basis for an excellent system which should
> be enjoyed greatly by many.
> 
> -------------------------------------------------------------------------
> 
> The main weakness, in my observation, of a pure p2p system, is that to
> gain access to particular data, the peer you want to communicate with
> needs to be available.  Some systems have gotten around single peer
> failure by persisting the data to all peers, but this is a horrible disk
> (and bandwidth) hog.  The solution is the following design, where each
> piece of software can work as a client or a server.  Each server would
> have a set of available "services".  The service and it's associated
> data can be linked to a service on another "peer" to create redundancy
> in case of failure.  One service is the "master" and the other is a
> "backup".  There can be an unlimited number of backups for a particular
> service, but obviously as that number increases so does the bandwidth
> usage to keep the backups up-to-date.
> 
> Think of a service in the current cxtable context as a plug-in.
> 
> TheServer
> ---------
> A system only act's as a server if it has a service (in either master or
> backup mode) running.  Each service can use either TCP or UDP as it's
> transport mechanism, and the server is in charge of doing the transport
> listening, and hands off the connections to the service.
> 
> The server should also support persistence of service data, and also
> service "backup" monitoring / updating.  This should make writing new
> services / plug-in's as simple as possible.
> 
> TheService
> ----------
> The service would get the data from clients (as either byte arrays,
> string arrays, or java objects (based on xml parsing)) through the
> server, and handle it appropriately.  They would be able to persist data
> by making calls into the server which it is wrapped in, and if there are
> "backup" services for this service, it's data is sent to those
> automatically to be persisted.
> 
> TheClient
> ---------
> The client would initially discover all services it is interested in
> (see ServiceDiscovery) and a list of "master" services (and the server
> they are connected to) is shown to the user.  The User can then choose
> to connect to a particular service.  There would be client software
> related to each service, and it would even be possible to have software
> which could handle communication to more than one type of service.  The
> client "plug-in" would register itself with the client, and if there was
> more than one client which could connect to a particular service, that
> list would come up for the user to choose which one they wanted to use
> (a default could be set so the list wouldn't come up).
> 
> 
> ServiceDiscovery
> ----------------
> There would be multiple modes of service discovery, all of which can be
> configured / enabled / disabled.  One would be a multicast message sent
> to the local network.  Each Server hearing the message would respond
> with a list of it's available services.
> 
> A client could have a set of IP addresses which it would connect to via
> a proprietary protocol to determine the available services.  This would
> be used if the server / services are not on the local network.
> 
> A set of URLs could be scanned, using a technique very much like is in
> place for cxtable now, to determine a set of IP addresses which can be
> connected to and asked about available services.
> 
> Persistence
> -----------
> There would be a generic set of methods to persist data.  These would
> link into a set of implementations, each of which would have a name
> associated to it.  This would allow multiple persistence schemes to be
> used simultaneously.  For example, a service could persist data to an
> implementation called "cxtable.persist.mysql.chess" which would be
> linked into a Class which uses JDBC to communicate to a MySQL database,
> and the chess database within MySQL.  In addition to JDBC
> implementations, an XML implementation and flat file implementation
> should be done at a minimum.
> 
> These would be implemented through an interface, so 3rd parties could
> implement alternative persistence schemes.
> 
> 
> Security / Service Ownership
> ----------------------------
> In the long run, I would suggest the use of a Public / Private Key
> system which encrypts all communication between all of the objects in
> the architecture.  Initially this will not be implemented, but the
> methods must be in place to do this so that it is designed from the
> beginning to support this, rather than retro-fitting it in after the
> initial implementation.
> 
> Peers would, through some mechanism, exchange public keys.  Each public
> key would be related to a particular user name.  A password will be
> generated by the user, encrypted, and sent to the peer.  The password
> will be checked against the peer's data (which is encrypted locally) to
> determine authentication.
> 
> All data (including discovery messages) will be encrypted, so that only
> a server can determine, based on the user's identity, what services are
> available to them.
> 
> -----------------------------------------------------------------------
> 
> I don't believe I have seen a system which supports all (or even half)
> of the functionality which I have mentioned in this email, and I don't
> consider it horribly outrageous that we may attempt to do this.  I will
> end up attempting to do this regardless, but another mind to bounce
> things off of, as you know, is always a nice thing. 
> 
> 
> _______________________________________________
> Cxtable-devel mailing list
> Cxt...@li...
> https://lists.sourceforge.net/lists/listinfo/cxtable-devel
> 
> _______________________________________________
> Cxtable-devel mailing list
> Cxt...@li...
> https://lists.sourceforge.net/lists/listinfo/cxtable-devel
>