Advertisement

Discussion: Untrusted, purely P2P, dynamic database

Started by August 11, 2005 07:16 PM
28 comments, last by Numsgil 19 years, 5 months ago
Quote:
Original post by stake
Not sure what you mean by p2p database??
Maybe you mean distributed database?? Probably.


No, a distributed database (at least by the wikipedia definition) implies a central management system.

With the peer to peer system I'm envisioning, the clients would directly be part of the database hosting mechanism, and would modify the database contents directly through specific "actions" most likely. These actions and results in turn would be accepted or rejected by their peers. Again, the earlier example, a peer will reject a modification which transports a target over 30 meteres in one second if that peer knows the maximum speed of that target is 3 meters a second.

Quote:
So is the querying distributed..or the data transfer..or both.


Both. The exact mechanics of the querying - specifically, finding out what peers have relevant information - could pose an interesting challange.

Quote:
If you mean a distributed database, then concurrency control will
overshadow security as a major difficulty.
How do you plan on tackling concurrency control?


Redundancy and statistics is what comes to mind at the moment. Nodes can and will constantly be comming on and offline, so a lot of duplication is going to be required. Concurrency control will be partially based on the same measures as the anti-hacking ones, absolute concurency is fairly hard to imagine. I should create a post on this alone, most likely...
So who would be the moderator-or controller of the data?
Suppose a client changes the world state and every other peer
accepts this, except for one that is also trying to access the same data.
Who wins? And how are you going to do the roll backs..you could have a roll back storm if the state is constantly being rolled back.
You could have a heirarchy of who wins..but then how do you distribute this heirarchy to the clients?

As far as querying(or searching in p2p)..what will be you mechanism?
I like a lot of the literature on heirarchical p2p networks, but it has its strengths and weaknesses...too many of the p2ps designed are just inefficient and waste bandwidth with their searches. I am not aware of how search engines work, but i know most p2p searches are pretty crude.

Having 100% consistency would of course be impossible...but most distributed systems have mechanism to eventually change the inconsistenct state..without this
a game would be unstable an unpredictable. The solution to this problem would be the conner stone of the design.
Advertisement
Where was my bloody "UserName Blank blah blah blah" :(
Please send e-mail to the gdnet folks to report the lack of this acknowledgement dialog as a bug, and copy/paste the URL of this thread in your report.

Regarding P2P MMOG, there are some academic papers on the topic, but I've never seen a convincing argument for why the system would "survive" after the "netsplit" when a gang of peers disagree with another gang; I've also not seen a convincing argument for how you can first proceed with an optimistic assumption about available resources, and then later undo based on higher-latency peer votes.

For example: there's a bag of gold on the ground over there; north of you, but south of me. You run up to it and pick it up on your computer; I run up to it and pick it up on my computer. I got the gold before your packets made it to me; you got the gold before my packets made it to you. Who gets the gold? This is the simplest of arbitration problems in a P2P system; once you go down that path, it starts becoming even harder (and if you include voting, well, please publish your results :-)
enum Bool { True, False, FileNotFound };
Not sure if i understood ya on a point.

Lets say A and B are both the same distance away from a gold coin. If both
pick the coin up at roughly the same time(assuming no clock syncronization)
you would have the peers(probably the closest in the virtual world) decide who wins. This works, but favors the peer with the lowest latency to its peer.
Depending on how much close interaction there is it could be a problem...only probably in very interactive 3d worlds or virtual reality.

The ideas for searching sound ok for games..but doesn't really work for p2p file sharing...unless you have mechanism to group like minded individuals close together...which is ok if you have certain groups you always search through...but any topic searched for out of the normal would require the peer to search away from its neighbors
Quote:
Original post by hplus0603
Please send e-mail to the gdnet folks to report the lack of this acknowledgement dialog as a bug, and copy/paste the URL of this thread in your report.

Regarding P2P MMOG, there are some academic papers on the topic, but I've never seen a convincing argument for why the system would "survive" after the "netsplit" when a gang of peers disagree with another gang; I've also not seen a convincing argument for how you can first proceed with an optimistic assumption about available resources, and then later undo based on higher-latency peer votes.


Basically, it dosn't survive - as a single piece. If a server is simply misinformed, a poll of random network peers with the data can determine what the majority believes, and thus what it in turn should believe. If a server is mallicious, it will continue to spout the misinformation and become ignored/blacklisted by the majority. The "bad" chunk falls off, that's partly the point. But there's no reason you'd want to keep malicious servers around anyways, this casting off is actually a good thing - it's self policing.

Although, in theory some of the "sane" nodes could get cut off as well if they didn't get accurate peer sampling.... hmm... that would be bad :3.

Quote:
For example: there's a bag of gold on the ground over there; north of you, but south of me. You run up to it and pick it up on your computer; I run up to it and pick it up on my computer. I got the gold before your packets made it to me; you got the gold before my packets made it to you. Who gets the gold?

Whoever reaches it first ;-). The way to deal with that situation would be with timestamps from semi-syncronized clocks, but I do see the problem (and it involves attempting to "speed hack" or similar...)
Quote:
This is the simplest of arbitration problems in a P2P system; once you go down that path, it starts becoming even harder (and if you include voting, well, please publish your results :-)

If I get anything worthy of publishing, I most definately will :-).
Advertisement
Quote:
Quote:
For example: there's a bag of gold on the ground over there; north of you, but south of me. You run up to it and pick it up on your computer; I run up to it and pick it up on my computer. I got the gold before your packets made it to me; you got the gold before my packets made it to you. Who gets the gold?

Whoever reaches it first ;-). The way to deal with that situation would be with timestamps from semi-syncronized clocks, but I do see the problem (and it involves attempting to "speed hack" or similar...)


The problem is bigger than just hacks. Who gets the gold if both players really do reach it at the same time?

Heres my solution. Both players choose the same number (by asking peers for one or some other method). Then the players choose two private random numbers and preform Diffie-Hellman key exchange. Then after the exchange the players exchange there private numbers (in plain site with no encryption). Then both players put the numbers into a special hash function that tells who wins.

Diffie-Hellman is needed because if the players just sent there private numbers then one could wait for the others number to arrive, then change theres before sending. Diffie-Hellman prevents this assuming that no one can solve a discrete log in a short amount of time.

This should prevent hacks and solves the problem of who gets the gold.
Quote:
This should prevent hacks and solves the problem of who gets the gold.


Imagine doing Diffie-Hellman for each potion quaffed, spell cast, shot fired, ste taken (if you don't allow co-existence in world space), ...

Of course, they need to tell their peers about the decision, and sadly you can't easily un-hack that. Even if I do a diffie-hellman with the peer, I may decide that I always win, and tell the world that the peer sent me a 0 and I chose a 1; it's my word against the peer's word at that point.

Peer-to-peer consistency for anything resembling real-time is a Really Hard Problem; and it gets worse in an untrusted environment.
enum Bool { True, False, FileNotFound };
Quote:
Imagine doing Diffie-Hellman for each potion quaffed, spell cast, shot fired, ste taken (if you don't allow co-existence in world space), ...
I didn't think about that.

Quote:
Of course, they need to tell their peers about the decision, and sadly you can't easily un-hack that. Even if I do a diffie-hellman with the peer, I may decide that I always win, and tell the world that the peer sent me a 0 and I chose a 1; it's my word against the peer's word at that point.
No one knows what the private numbers are (except the creator) untill after diffie-hellman. Because of that the other peer cant chose a number that will make him win.

But like you pointed out its not practical to diffie-hellman so it doesn't really matter how secure it is.
Assuming two peers compete for a gold coin.

Peer A picks random number Ra; Peer B picks random number Rb; Diffie-Hellman exchanges these.

Now, how does the rest of the world know which peer got the gold coin? Both Peer A and Peer B need to tell the rest of the world about the update in world state (because the gold coin went away, and some peer got more gold in their inventory).

Now, suppose that after the Diffie-Hellman, Peer A tells the world "I won, because I picked the number 7 and B picked the number 2" and Peer B tells the world "I won, because I picked the number 5 and A picked the number 1" -- how do you tell who's cheating, and who's not?

enum Bool { True, False, FileNotFound };

This topic is closed to new replies.

Advertisement