Subject: [p2prg] P2P: goals & prospects?

From: Ivan Shmakov <[email-masked]>
Date: Sun, 25 Jul 2010 14:29:05 +0700

I wonder, how are the goals and prospects of deploying P2P
	technologies are currently imagined by those working in this
	field?

	(I've put some bits of my own understanding of the problem
	below, and would appreciate if someone could comment on them
	and, if there any, provide relevant pointers.  TIA.)

* P2P filesharing

	To me, the basic idea behind, say, P2P filesharing looks like:

	• (from the publisher's standpoint) no need to manage
	  transfering a copy of the material being published to each of
	  the recipients; only a few copies are to be distributed, and
	  if the thing catches on, the rest will be shared by the peers;

	• (from the user's standpoint) improved download time.

	The other obvious benefits over the “traditional” file
	distribution means are:

	• its easier to authenticate the “token” file (say, .torrent),
	  which, in turn, authenticates the bigger file; this contrasts
	  with the use of, say, HTTPS, which effectively prevents
	  caching at proxies; also, the token file could just as well be
	  passed over e-mail, secured with PGP (GnuPG) or S/MIME;

	• there's virtually no chance for the distribution service for a
	  particular file to be discontinued, provided that there's
	  continued interest in the file;

	• the anonymity is somewhat easier to implement.

	(These points preasumably attract interest to the problem from
	the libertarians' and other such groups.)

** Fight your neighbor vs. Help your neighbor

	I guess that it's pretty typical situation when multiple users
	are sharing a single connection to the “outer world”.  With
	“traditional” data distribution techniques, the users
	downloading a single file effectively become contenders for the
	limited bandwidth.  However, with P2P-based distribution, no
	contention takes place (ideally), and each user just downloads
	its own part of the file, which is then added to a kind of a
	“common pool”.

** Searching for peers & authentication

	So, there're a lot of users having some bits of a bigger file,
	which they're ready to share.  How could they find one another?

	Basically, we need:

	• a unique identifier for each and every of the files; for
	  obvious reasons, a content-based hash (either “full”,
	  piecewise or tree) is used as such an identifier;

	• a database (centralized, or based on distributed hash tables,
	  such as Kademlia) to track the peers involved in distribution
	  of a file.

	The latter point implies that there's to be a unique peer
	identifier, such as a TCP/IPv6 or TCP/IPv4 transport address.

** IPv6

	Thus, getting the best of the P2P approach implies:

	• globally-unique peer identifiers;

	• global peers database (either centralized or distributed);

	• the possibility of the connection between any two of the
	  peers.

	It's clear, however, that NAT-ed environments make the above
	either hard (with, say, UPnP-based NAT traversal, which both
	requires explicit support within the user's software and may be
	insecure), or impossible (if no such facility is available.)

	The deployment of “local” BitTorrent trackers has seen some
	success, but it's plainly inconvenient in the general case.  And
	wasn't it the purpose of Internet to hide the details of the
	network topology from the user, anyway?

	Thus, the wide deployment of IPv6 should be quite benefical to
	the P2P (filesharing) users.

	BTW, do I understand it correctly that by now the number of
	“usable” IPv4 addresses is within an order of magnitude or two
	to the total number of P2P filesharing users worldwide alone?

** P2P filesharing for a casual user

	What a casual user may expect from a P2P filesharing
	implementation?  How it could “look like”?

	Let me imagine a “box” — be it either a separate network host,
	an OS component, or a part of an Internet-aware consumer device
	(e. g., a digital video recorder.)  The box will:

	• allow the user to specify the materials of interest (along
	  with their respective priorities), including periodic ones;

	• will download and place (“cache”) these on a non-volatile
	  media (HDD, SSD);

	• will allow for the materials to be uploaded and will identify
	  those using either a centralized metadata database (like
	  Bitzi), or in a P2P-manner;

	• according to the user's preferences, will “expire” the
	  outdated content; the “rarity” (both global and local) of such
	  may be taken into account;

	• obviously, will allow “accessing” those materials that are
	  available (either in full, or in part that's enough to allow
	  for such an access);

	• last but not least, such a device or component has to support
	  a standardized API, so to enable other software and devices to
	  use these functions (say, a GIS tool may request satellite
	  imagery via such a “box”; but that's a story for another
	  article.)

	Each of these “boxes” will comprise a part of a kind of a P2P
	storage and distribution infrastructure.  The more there will
	be, the better the user's experience will be.

	It's also tempting to imagine wireless ad hoc networking
	capabilities for such boxes, as it will allow for these to
	comprise the networking infrastructure itself.

* Towards P2P computing

	There're currently a number of on-line resources that perform
	various kind of data processing for casual users.  Say, it may
	be the conversion of a document to PDF or DjVu.  There're
	apparently some interest in hosting geospatial data processing
	services for the benefit of those users that aren't themselves
	technically fluent enough to deploy these at their own hardware.

	IIUC, the approach is envisioned by its proponents as a
	“conventional”, non-P2P system.

	But let us imagine that there're a number of centers that
	perform various kinds of data processing.  Then, there're may
	also be some data processing software at the user's side.  Could
	we imagine a system that, given a user's request for a certain
	“target” dataset, will calculate the path for the data from the
	place (or one of the places, since we assume that P2P
	filesharing is used) it's located to the user's host, with the
	intermediate peers performing the relevant data processing
	steps?

	Such a system will need to take into account:

	• load and the capacity of the links;

	• load and the capacity of the intermediate processing nodes;

	• load and the capacity of the user's own host;

	• the possibility of the failures for both the links and the
	  intermediate nodes;

	• the availability of the relevant software at each of the
	  nodes;

	• the “trustworthiness” of each of the nodes, as specified by
	  the user.

	To my mind, among the other issues, this approach, if properly
	implemented, will relief some of the concerns over the software
	as a service (SaaS) idea, as the user will (preasumably) be able
	to host the relevant software on its own host and use it instead
	or to validate the data produced by a network service.

* Conclusion

	Suggestions?

	TIA.

-- 
FSF associate member #7257