[news.eclipse.technology.ecomm] Re: Why the emphasis on P2P?

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

Hi John,

Thanks for your note.

I agree p2p is a somewhat misleading term (since it means different 
things at different levels).

We are mostly focused on 'p2p' at the plugin programmer level.  We would 
like to provide a communications architecture that allows plugin 
developers to develop fully distributed applications...i.e. those that 
have behavior and state (at least in the limit) runs on any/all of the 
participating processes.

John F. Patterson wrote:
> I suppose this question takes several forms.
>
> 1)  What do you mean by P2P?
> In my experience this is a very misleading term.  At a system level it 
> seems to indicate a desire to avoid the use of servers, presumably to 
> avoid single point of failure.  As a practical matter, most P2P systems 
> are dependent on servers if only as directories.
>
> At the programming level, P2P simply means that the programmer does not 
> need to worry about servers.  Often as not, this is because the servers 
> have become part of the presumed infrastructure.  We certainly treat 
> TCP/IP that way, since we rarely ask whether the routers are there.  We 
> just assume they are.
>
> At the user level, P2P often just means that the user does not have to 
> think about the server.  Presumably, the application hides the use of 
> servers.  (And the administration of the servers is so reliable that no 
> one ever sees the difference: :-) )
>
> 2)  Given your focus on virtualization, why do you care about P2P?
> Ideally, our virtualization of conferencing would be agnostic about 
> whether we have a server-based implementation or not.  So, why raise the 
> issue?

The reason we brought it up in the proposal was to distinguish this 
project from a pure client-server architecture.  I weighed the use of 
the term 'p2p' and decided to use it rather than to try to explain some 
other term in a short proposal.

> Are you uncertain that a single virtualization can embrace both 
> server-based and P2P implementations of conferencing?

No, I'm not uncertain.  I'm quite sure that it can.  Personally, I've 
designed and implemented such virtualizations 3 times previously, and I 
know that others also on the team have such experience.

> 3)  Is it possible that P2P means only two participants in a conference?
> The general view of a conference is that it is a multi-point 
> communication context.  Clearly, things get a little more difficult when 
> you start to worry about more than two participants.  Is it possible 
> that you are using the term P2P to indicate a lack of interest in 
> conferences that involve more than two participants?

The notion of a 'group' or 'session' captures '2 or more'.  This is the 
way I've been thinking about virtualizing 'anything with 2 or more 
participants'.  Yes, things get more difficult (e.g. wrt failure 
handling/reliability, performance, message ordering, etc) with three or 
more participants, so that's why the emphasis in the proposal on the 
full multipoint case.  2 can be considered a simple case of n.

> 4)  Given some of the services you indicate an interest in supporting, I 
> am surprised that you use the term P2P at all?

Well, it was a choice between using p2p, and explaining 'programmer 
distributed' in this proposal.

> You indicate an interest in authentication, presence/awareness, and 
> provisioning.  Aren't these usually server-based services?  

They certainly can be/typically are with most current services.  It is 
possible that some/all of such services could be provided by a peer.

>Is it a goal
> of the effort to ensure that these services can be made peer-to-peer as 
> well?

I would say that it's a goal that these services (and any other 
services) *could* be developed via p2p (we need a new term, don't we). 
That is, one of the clients could be the 'authority' wrt authentication, 
presence/awareness, provisioning, etc.

But, since we want to support existing protocols as much as 
possible...to provide interoperability with existing clients/servers, I 
expect that we will provide implementations that use existing servers to 
provide many of the services you describe above.  This will not prevent 
us or the Eclipse plugin developer community, however, from providing 
such services via peers.  In fact, I expect we can enable and encourage 
that.  Particularly with some work on using the OSGI model to 
standardize how services are created/added/removed/managed/secured by 
each individual Eclipse participant.

Thanks again for the questions.  I have some regret over using p2p for 
brevity, and so perhaps as the proposal moves forward it can be replaced 
by something more appropriate and less over-used.

Scott