next »

[Klaim]

See http://labs.bittorrent.com/experiments/sync.html
To sum up: this is a peer-to-peer bittorrent-protocol-based DropBox-or-GoogleDrive-like tool. Still in alpha.

I am thinking that maybe it would be a good way to host files for no money.
However, it would require to build some installer/client soft to work with it to make it invisible to a lambda player that she is using this technology to get a game (or any other kind of data).
I don't know about the case you want one file to be shared only by paying clients. Maybe generating different keys per payment?

Some TIGers are more knowledgable than me on the subject of file hosting, game distribution, DRMs, etc. so I'm posting this here for info and thoughts.

[ஒழுக்கின்மை]

generally i don't like peer to peer for distributing files for indie games, because the download speed is somewhat proportional to the number of seeders available. with indie games, often a game isn't popular enough to have too many seeders. if you have, say, 10 seeders, the download speed will be very uneven, it may take hours to download a file that would take minutes if hosted on amazon s3

i think it can be useful for games that get very popular though. for example, it'd work for a game like minecraft. i'd consider doing it this way only if hosting costs were so high that it'd be worth it to set this up; e.g. if i was spending hundreds of dollars a month on hosting costs, then this would obviously help a great deal. but if i'm only spending like $10 on hosting costs a month, then this is kind of pointless

[Klaim]

I'm not sure if it's exactly the same kind of performance than classic peer-to-peer via torrent sharing, because it's apparently optimized for low number of nodes (your personal computers).
I'll try to find concrete data on this.

[Udderdude]

How does something like this handle game updates?

[Xienen]

It looks like 1 machine or set of machines can be marked as the "host" of the files.  Every other machine is read only and either has some versioning system built in or just uses MD5/modified time to check with the host to see if there are new files available. If other read-only users have the files already, they can download from them, as well.  The whole idea behind the thing is to handle something like game updates, it seems.

[Klaim]

It looks like 1 machine or set of machines can be marked as the "host" of the files.  Every other machine is read only and either has some versioning system built in or just uses MD5/modified time to check with the host to see if there are new files available. If other read-only users have the files already, they can download from them, as well.  The whole idea behind the thing is to handle something like game updates, it seems.

Yeah basically if you change the host file and allow only reads and shares, you got automatic updates.

There are potential problems with that:
 1. the (custom) client need to apply updates only on appropriate times, like, not when the game is playing (I think it's not a problem on solo binary but it might be a problem with shared libraries loaded on the fly);
 2. the client need to manage user rights like any other install/update system, but I'm not sure if in this specific case there would be some other additional cases to manage.

[_Tommo_]

I would go with an hybrid approach: the client calls your server which tells how many updates it needs to install ID and provides the DHT string for each file; then it uses BT to download the actual zipped (and diffed?) updates.
Your server would run bittorrent too, to have at least one seed always there... the advantage is that if your game becomes successful you won't be killed with the traffic of thousands of users trying to download a patch :D