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

[Williams, D. <DAV...@ca...>]

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