Slashdot Mirror
Managing Bandwidth and Bandwidth Costs?
"I'd like to illustrate the second concept. When you have your (for example) T1 and you're not really using it, you are still paying for all that bandwidth. It's like the car that sits in your garage, you're still paying insurance and car payments on it even though you're not using it. But then you put up a new game, serve new media or suddenly become the 'Site of the Day' and your bandwidth is flooded and maxed out. For that case, it's like you've bought a car that only goes 40 miles an hour but while the demand exists and only while that demand exists, you need a car that goes 150 miles an hour. You don't want to pay the money for a car that goes 150 because you only need it occasionally. Later, you know you'll need that car to go 220 but you're not there yet.
So if this makes sense with regards to bandwidth, it is like you'd want burst-bandwidth depending on need. Do any of you face this problem? If you do and have solved it, I'd love to hear about your strategy. Once this is solved, we get back to the first question, how do you manage that cost, put a number on it and either fit it in to your business model or pass it on to your customers?"
Agreed on Akamei. Why reinvent the wheel? You'll spend more money trying to hack something together with sourceforge bits than you'll pay Akamei. Also, their services work right now, unlike what you have now, or 1 year into the future.
Is there any reason an FTP server couldn't support bit torrent as well?
The combo of the two would be great for moving distributions and other mirroring of publicily available data.
If you had to pay for your bandwidth, would you give it for free to some company from which you are currently downloading a product update? I wouldn't...
the problem with the logic of the second link is that they assume that users of bit torrent close the client after their download is done. The study of any popular files shows a great number of seeds, as many people find it only fair to leave their client open as long as possible (i try to redistribut the file 10x whenever i download it, which is about 3 days open for the files i download). Because he does burst files, it would be very similar to a new eps released on BT, as a surge of people will ensure at least a week of incredibley fast download speeds. Also, he could hash it on the eD2k network and set up a link for that, as well as encourage people to share it on the eD2k network (think new release on sharereactor).
YOU SUCK BALLS!
There was a time when selling software without a manual was considered unprofessional. Now you can buy software online and get NOTHING except for the string of bits - not even a CD.
Indeed, as soon as we all have 50mbps connections (and file sizes remain the same), the question will no longer be asked. But it won't be due to P2P, just due to the cheap bandwidth.
P2P is severely overrated. It's not a solution for anything that doesn't involve sharing illegal files. If everyone on P2P is on a standard 128k/768k ADSL connection, it will not work -- there will be more demand than supply. It only works when there are nodes with a fat upload line that never download anything. But those are quickly disappearing since organizations figure out that their fast internet connections are being abused.
If you seriously think that P2P will solve any problems besides distributing warez, you are wrong. P2P is a hack, unlike the client-server paradigm. The real solution here would be multicasting and other intelligent routing that would basically mirror the broadcast model. P2P is nothing more than a band-aid.
If you still don't believe me, just think about this: how can each node connect to 20 other nodes that have the same file and aren't busy downloading it? Mostly due to people's benevolence, but that would not work in a production environment. If I need to download a BF1942 patch, I'll get it and delete it, I won't leave it on my machine for a few more weeks. You can't expect people to share stuff indefinitely. The client-server model is much simpler and much more scalable than any P2P solution.
Argh! Must...read...source article...closer...
to clarify, it was a FreeBSD x86 server. The
largest ftp site in the world.
For every annoying gentoo user, are three even more annoying anti-gentoo crybabies. Take Yosh from #Gimp for example.
P2P realizes the two facts that you obviously don't:
1) Not everyone uses their Internet connection 24 hours per da
2) Most people don't need hard drive space these days (i.e. storage is cheap)
Combine these two developments, and you have a lot of upload bandwidth sitting idle. I would argue that P2P becomes MORE effective, not less, as you move to legitimate files, because people are more likely to leave it running when they aren't afraid of the RIAA/MPAA tracing their connection down. Since ISPs have been reluctant heretofore to ban P2P traffic (after all, it is a driving factor for adoption of high-speed Internet access), all those hours people are sleeping with a P2P program open is free downloads for the rest of us.
There are valid complaints against P2P (untrusted incoming executable data, very high latency, no centralized validation of data, etc.) Use them instead of the bandwidth non-issue if you don't like P2P.
They will do it if saves them money or if the alternative is simply not to host large files. Many sites already allow or even require you to have special download managers (Fileplanet etc.). What if they provide special rebranded versions of the p2p services? Instead of running "BitTorrent" you're using "Symantec AutoUpdater 4". Or some tiny general client could be delivered automatically like Macromedia does with Flash.
Using BitTorrent as the back end just make sense, you have a server serving the files, just like a standard web server (in fact, it could be the web server). That provides you with a base level of service. Then on top of this guaranteed bandwidth you add all the unused bandwith of whoever happens to be downloading at the same time. Suddenly your paltry T1 turns into a T3 and even the bean counters start to take notice. The key is hiding all this P2P stuff from the user, the end user just clicks on links and the download starts.
BitTorrent exists me a lot. I hope to create an apache module for drop-in deployment for torrent hosting some day.
(Author here)
What you're missing is that if you end up using your client's bandwidth to distribute your software without their knowledge or permission, you're screwed.
In serving the general public, something like this would be subject to a large negative reaction not to mention the problem of "have you ever gotten a file from bit torrent that was invalid?" I have.
Though technically neat, practically, it's unfeasable for a mass market product.
1) You can't impact/rely on the user base to help you deliver your product.
2) Added chance for error introduces risk and jeapordizes your distribution model and therefore business model.
- Zav - Imagine a Beowulf cluster of insensitive clods...
He'd be happy to make money customizing it for people...
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
What I would do is colocate all my servers in a datacenter.
Take a burstable bandwidth, let's say that can burst to 100mbs, but to control your bandwidth in most time to ensure you do not go over the cost, you configure your router to not allow more than let's say 1mb of bandwitdh or whatever you want as a maximum and willing to pay for in normal time.
You should then monitor your bandwidth usage in real time, as well as the logs on the machines, and adjust the traffic shaping to the amount of traffic you want to allow.
For example, you know what on that day, you will do a marketing operation, and you are willing to spend $xxx more for the bandwidth, you then change your setting right before your marketing plan to the maximum of bandwidth you are willing to pay.
my 2c...
Who in their right mind modded the parent to +5???
"Bandwidth trading" escapades have bancrupted Williams and contributed to Enron having to go ever more aggressive with their "creative accounting." It reeks of the same foul smell as the "real options" nonsense. (Note: the article referenced even has "real options" in the keywords).
Basically you've got a whole bunch of not-so-smart people who can fake expertise in nearly anything as long as they don't get their hands dirty (aka academics) colluding with some not-so-smart MBA's in executive positions - and then you've got a problem for everyone around them.
This is a problem that needs to be priced based on actuarial type methods (a'la insurance). Just because you can write a (usually bad) price process for "bandwidth" doesn't mean that you can logically apply all the consequent financial mathematics.
And, here's a party-pooper - real options are not options at all - no matter what tenured clowns like Pindyck and Dixit want you to believe.