Re: [Cxtable-devel] A longer reply to "p2p, the next generation"

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

A "Server" is really just a piece of code in each "peer".  This part of
the peer software (which each person would run), would include the
server, any services they have installed, and the client code.  A Server
includes registry logic, persistence logic, service replication logic,
and user authentication / authorization logic.  The server is really
just the wrapping through which a service sees the world, which is made
up of it's clients, and it's persistent storage.

A service is started by the server (when the user commands this to be
done, or by default when the program is started if it is configured in
this way), and then, based on the service's configuration, when it
persists information, the server will send that same information to
other server's which have are designated as "backup" services, to
persist the data there as well.

Your point about how the client currently works is the largest
divergence from my thoughts, as what I think this idea really turns into
is a kind of hybrid p2p / client-server model, though it is flexible
enough to be a pure p2p, or pure client-server model, based on the
configuration.

I will now give some examples of usage, which I hope will help to answer
any other questions you might have, but if they don't, please feel free
to ask more! :)

> Alice starts up the supercharged new cxtable (I will call this sxtable
for now).
> Alice starts up a file sharing service (through the server UI).
> Bob starts up sxtable.
> Bob starts up the file sharing service, but in "backup" mode, and
connects it to Alice's file sharing service (he needs permission to do
this, which he already has from Alice).

> Charles starts up sxtable.
> Charles has a URL which lists a number of peers which are sometimes up
running the file sharing service and types it into the UI (or it is
saved in his preferences and he doesn't need to type it in).
> Charles gets a list of file sharing services which are currently
available (found through the discovery process).
> Charles starts up his file sharing client, and connects to Alice's
service.  The client may or may not support connecting to more than one
service at a time
> Charle's client finds out that Bob is a "backup" for Alice, and
remembers this.
> Charles downloads some files, and uploads one.  This causes Alice's
file sharing service to persist it to disk, at which point the "server"
knows that Bob is a backup, and send the file to him to persist as well.

> Alice's system crashes.
> Bob's server detects this, and starts up the service.  A service in
backup mode doesn't need to be fully running, the server only needs to
know how to persist the information for that service type.

> Charles can now connect to Bob's system, and continue uploading /
downloading.

> Alice's system comes back up, pulls over the persistent data from Bob
and tells it to go back into "backup" mode, once no clients are
connected.

In this example, if the client software supported it, Charles could
connect to a large number of file sharing systems at once.

Overall this solves one of the biggest problems of peer networking, in
that you might not be able to get to the data that you want to, but you
don't want to have the data EVERYWHERE because that is a huge waste of
bandwidth / space.

Also, with things like chatting, rather than having all the messages
sent to everyone, you can have a single system, a "server" of sorts,
which everyone chats through, but if it goes down, other can be set as
"backups", so the conversation can continue seamlessly if the server
goes down.

One of the guys that invented Lotus Notes is involved in p2p software
now, and I can't remember the name of it now, but I used it for quite a
while, and it was rather nice, with a shared whiteboard, shared
calendar, chat system, and some other stuff (including file sharing),
but it stored everything on each client (they have a version you can pay
for though, that creates a server which holds stuff).  Despite the
ability to "serverize" some of these services, it still lacks a great
deal in the fail-over / reliability area, and everything is encrypted,
but their security scheme still blows, IMHO.

I want everyone in the world to be able to host a set of services on
their home machine, and with more and more people getting broadband and
leaving their machines on all day long, this makes more and more sense.

I could then set up some file system space at home, for family pictures,
my mother and aunt could run "backup" services, so that if for some
reason I go off line (which doesn't happen often), everyone can keep
getting the data, and I can get updated when I come back on-line.

I see this as the ultimate group-ware, since you can still be in
client-server mode if you want, or each person can keep their files on
their local system, or you can tailor make your service network in any
way that is appropriate to your application.

There could even be a service which acts as a client in a knowledge
"group" to obtain information about all available files in the group. 
Then rather than having to connect to each peer, you can just connect to
one of the knowledge managers to get the information.

There are a nearly infinite number of uses for this technology, I think,
yet I feel that this sort of thing has never been implemented in the
correct way.

I hope I have not rambled too much, and perhaps even answered some
questions along the way.

--bjgm

On Wed, 2002-01-02 at 16:33, Williams, David wrote:
> Borne-
> 
> OK.... 
> 
> I am assuming, then, that a Server is a persistent thing...?  It is always available, or this is incorrect?  Either way.... I would make this akin to my mind to the current Registry server process (which also handles relay communications when direct, and peer-enable, both fail..)..  It could handle many other processes as well..but at this time, does only those two...  
> 
> The Service..  These services, run, then, on the Server, and cache to their backup?  Or did I miss this point?  
> 
> The Client...  This client has a list of services it can connect to... This is definitely a planned but lacking feature for cxtable.  Cxtable assumes that everyone connected to it wishes to connect to one another... the persistent connection between each peer eventually allows the runner of the Registry server to pull down that server process, and have a set of X people connected with one another, but closed off to the rest of the 'network'..
> 
> Service Discovery...
> URL-scanning is good.  I personally like the PHP-piece, as the act of registering a server for the availability of use to clients can be done with a URL scan as well..  Either way...this basic idea does seem to be in line with how I do it (or hope I do)
> 
> Persistence...
> I have given no thought to persistence.  These ideas seem valuable, for sure..
> 
> Security/Service Ownership..
> Contrary to what the code would tell you.. I have given thought to security...  Relating to public keys...  these keys generally can be published anywhere (hence their name) and could be provided along with the peers other information (IP, port, etc..), unless your intention is to route all communicae through a Server, and then, if course, only the server would need to know it...  
> 
> ---------------------------------------
> 
> Each of the above points has merit with relation to the project I currently have, and at the same time..  I pause... as there are one or two points that I am unsure of..
> 
> Is the goal of the p2p to have places that relay which are persistent?  Because this vision does give way to a couple of weaknesses...  One of these weaknesses is that if they can pin down where you are, and where you'll always be...  Then they can shut you down....  The other is the need for a certain type of cash-flow to support the persistent servers... 
> 
> However, as I continue to read through this, I am of the belief that the servers you speak of could be EITHER a persistent server in the traditional sense, OR a peer-type server that is fairly transient...  
> 
> Change is not a bad thing...and this is definitely the type of thing I set myself up for by inviting new creative blood to come look, to come help....
> 
> I think that the changes you propose are worth pursuing.  I think that certain services, under the new modified vision, would allow for the "Intranet over the internet" concept to remain, and at the same time widen the vision to incorporate many other takes..
> 
> This is all assuming that you haven't decided to ditch me for Grapevine ;-)
> 
> ~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...
> 
> 
> _______________________________________________
> Cxtable-devel mailing list
> Cxt...@li...
> https://lists.sourceforge.net/lists/listinfo/cxtable-devel
>