Bit Torrent
-
i didn’t realize this thread existed, but i’ve been working on this feature.
[quote=“Bjorn Jentoft, post: 35888, member: 587”]
I have actually done bittorrent downloading for imaging for a few years. However, I have been downloading the image file the normal bittorrent way. to a temporary partition, without piping it, and then running the actual imaging process and cleaning up the partitions afterwards. This is a delay in the process I would like to get rid of.[/quote]if you had shared this, you could have saved me some work. lol
-
There’s a FOG alternative developed by some people from spanish universities that support BitTorrent for cloning. It’s called OpenGnsys ([url]http://www.opengnsys.es[/url]).
I’ve tried it a couple times, but the client side interface doesn’t catch me at all.
-
for anyone interested, torrent-casting is now functional in the current svn, but it does require a few steps to be done manually at the moment. if anyone is interested in trying it out, i can walk them through it.
-
is this the server distributing it to clients primarily or do the clients play a big part in distributing to each other now?
-
It starts with the server or wherever you first start seeding from. At tasking time, the clients download the image to a partition. Once its downloaded it is peered out as expected. The more download tasks the more peers there are.
-
Are you thinking this could replace multicast? (which has had a ton of problems)
Or possibly become the main method of distributing images?Can the clients peer the parts of the image they have already in chunks or does it need the whole image to download to become a peer?
Is there a configurable time after the image finishes downloading on that machine that the client reboots to allow getting into the new OS, so people could have 5 minutes peering to speed up others and then reboot?
Is there a tracker/torrent file that could be added to other torrent clients? easy setup storage node…
-
[quote=“VincentJ, post: 36284, member: 8935”]Are you thinking this could replace multicast? (which has had a ton of problems)
Or possibly become the main method of distributing images?[/quote]
i’m thinking of this being an alternative to multicast, but so far as i know there isn’t any intention to drop multicast support
this method won’t become the “main” method of imaging for a few reasons, one of them being that it isn’t as fast as unicast if you have hardware that can keep up (server, network, and client)i don’t even know if it’s faster then multicast (since i’ve never gotten multicast to work, or tried very hard to do so)
[quote]Can the clients peer the parts of the image they have already in chunks or does it need the whole image to download to become a peer?[/quote]
as per a normal bittorrent download, the file is split into small “chunks” for transfer, and all clients that have downloaded a chunk can share it with others as soon as they get it
[quote]Is there a configurable time after the image finishes downloading on that machine that the client reboots to allow getting into the new OS, so people could have 5 minutes peering to speed up others and then reboot?[/quote]a client continues to share the image while the computer is using, it only stops sharing when the computer is done imaging, so all clients should have a reasonable amount of time to finish downloading before clients stop sharing
[quote]Is there a tracker/torrent file that could be added to other torrent clients? easy setup storage node…[/quote]
yes, that is part of the intention. it is compatible with any standard bittorrent client, qbittorrent has been working best for me, for windows -
for those interested, torrent-casting is not functional in the current SVN
changes have been made to the way that fog handles partition structure and other elements of imaging. these changes will be transparent to the end user, but greatly increase the overall capabilities and compatibility of fog. these changes did, however, undo much of the work done toward torrent-casting. while i plan on working to re-implement torrent-casting, i felt i should inform everyone that it could be a while before this feature is brought back. -
It’s alright, you can blame me.
-
[quote=“Tom Elliott, post: 39160, member: 7271”]It’s alright, you can blame me.[/quote]
Improving the core functionality of fog is more important then retaining compatibility with a new experimental feature. So, ok, i blame you for improving the core functionality of fog.
-
Any chance of torrent cast working anytime soon I just deployed 400+ images this weekend and could have really used it.
-
@Joseph-Hales i hope to resurrect the method, but it’s going to be more complicated than the last implementation. i’m up for the challenge, it’s just hard finding the time.
-
You go, /u/Junkhacker! I would love to have bit torrent sync, so long as it allows me to lower my overall deployment time when doing 6+ clients.
I can’t use multicast because that hurts our network in a VERY bad way (all network traffic basically halts), so I use 5 concurrent single casts typically to about 30 computers at a batch.
Thus, whatever you do, my deplying to 6-10 clients takes about 2x as long as 1 client does. If the torrent send can reduce that number for 6+ to 1.5x of 1-5 clients, then I would be extremely happy and would find great benefit for my company.
If it works as good as possible, I would expect total deployment time for 30 clients to be like 15-20% of what it currently is.
