[p2p-hackers] A Question about user awareness in p2p

[Greg Bildson]

> On Tuesday, March 22, 2005, 8:46:09 PM Anoop Mavilaveettil
> <anoopsmv at gmail.com> wrote:
>
> > Well it is not that simple.
> > 1)First, it is not necessary or mandatory that "two people are always
> > in each other's buddy list". A user might have added another user in
> > his buddy list, but not the other way. In this case when the second
> > guy comes online, the first guy would never get a notification.
>
> It is not necessary for the list to be the buddy list of course. You
> could keep a list at each user where you add people to be notified
> automatically.

You can't update your list of who to notify when you are offline.  Thus, the
DHT would have to store that information at the least.

>
> > 2)Second. One major issue, that I have to point out, is that  I'm not
> > talking about peers, I am talking about users. A user can connect to
> > the p2p net using any peers.
>
> > Let me explain a common scenario
> > a) User1 connects to the p2p net using peer1.
> > b)User2 connects to the p2p net using peer2.
> > c)User1 using common message mechanisms add user2(NOT PEER2) as his
> > buddy. But the main thing to note, is that User2 doesn't even
> > know/don't care to know about user1 adding him to buddy list and user2
> > never adds user1 in his buddy lists.
> > d)User2 disconnects from the p2p net. At this time, we can possibly
> > have some notification mechanisms, which will notify user1 at peer1 about
> > the disconnection of user2.
> > e)User2 connects to the p2p net from peer3. ---> And here lies my
> > issue. How would user1 at peer1 would know about the arrival of
> > user2 at peer3( without structured or limited flooding?)
> > NAT traversal and all other issues are lower level ones, and solutions
> > for those issues are well documented and easily available on the web.
>

I don't see how logging on to a third peer would be any different than
logging on to a second peer.  The only potential problem that I see is that
when moving computer to computer, you can't store state and thus need all
information (including your own buddy list) stored in a distributed database
with security and privacy measures in place for access.  The network would
need to store your information permanently.

This is an area that I have been thinking about for quite a while.  How
could you build a distributed friendster for example?  I presume that it
would be fairly hard to build a perfect fault-tolerant P2P database.  To
achieve this more easily it would be useful to have a third class of network
resources that could provide a longer lived source of data.  These federated
data servers would not need to be totally centralized but hopefully, they
would also not be totally transient like standard P2P clients.  The P2P
clients could upload a timestamped version of the data from the federated
data servers for heavy access and indexing purposes during active use.
Publishing changes would have to go back to the data servers.  Ideally, some
users would be willing to run these longer lived servers and provide this
resource to their network of interest.   The alternative to these hosts
might be to detect long uptime clients and make use of these as data hosts
with heavy replication.  Anyways, this may be totally different from what
Sreedhar was asking about but I find it to be an interesting question.

Thanks
-greg