Hello I thought of making a Software which will reduce your Internet cost by compressing all data going to and coming from your computer.I wanted to know how much will it be helpful if I could reduce your data consumption by nearly 70% to 80 % ??? ???
I will use java for this purpose.Please comment on my idea… :persecutioncomplex: :persecutioncomplex: and also include useful suggestion…
Most textual content (html, plain text, email) is gzipped already.
Media (audio, video) is highly compressed already.
What is your ingenious plan to cut down datatraffic by 80%?
Is internet cost even by data anymore (atleast in America)? I don’t pay for my internet (being 16 and all) but I’m pretty sure my parents just pay a flat rate for internet speed. It may he different in other countries but I don’t really care about how much data I consume.
Ok I will upload the soft. soon : ;D
That’s not quite how it works. An ISP (Internet Service Provider) needs to maintain an infrastructure to provide adequate bandwidth to customers. If data traffic surges, the ISP has to invest in hardware. These costs are spread over the customers, which means your flatrate plan gets more expensive, or your bandwidth/FUP is affected. Advances in hardware capability and efficiency offset this increase in price. If everybody were to reduce their data traffic by 80% it would create a shockwave through the industry (where service/content-providers would immediately jump in to find new ways to utilize this vast untapped existing infrastructure).
TL;DR: you do care :point:
PPP already offers compression though? (CCP)
If any given ISP wants to reduce bandwidth at the expense of latency and processing cost they’re free to use it?
The end user shouldn’t worry themselves with such issues; they’re solely a concern of the network provider.
Tell me if I get something wrong here,
but no matter how much your computer compresses the data it recieves, it only recieves the entire file and compresses it clientside then, but doesn’t decrease the amount of data recieved at all unless you also make the server use the compression method and send the compressed data…
The same goes for your upload, if you compress it clientside, the server will simply not be able to use this data, unless it knows how it has been compressed.
So how exactly do you, leaving the asked question apart, even plan to do this?
Typical approach is to have a server on the Internet backbone, acting as a proxy & doing all the compression of downstream (and decompression of upstream, where applicable).
Examples: Chrome’s DCP, Mozilla’s Janus, Opera’s Turbo.
It’s really only of meaningful applicability in the bandwidth constrained world of mobile internet, and even that is rapidly contracting.
I could even believe in you, OP, but when you said you were going to use Java, I lost all my faith.
And I’m not saying this because I hate Java; instead, it is because I have a very large experience with Java (3 years and a half), and I KNOW that this is impossible. Just, impossible.
And, even if you used a low-level language or JNI, I’m still pretty sure this is impossible. You are probably just a kid saying things you’ll never do to gain attention.
Why is it impossible? It’s immensely impractical, but not impossible (aside from the 70-80% statistic).
BloodShura, 3 years is not “very large experience”, as numerous people on here have 10+ or even 15+ years of experience with Java. I also don’t know quite how experience with Java correlates with an understanding of whether this compression is possible. Also, jumping to assumptions like OP being “a kid saying things” is kind of silly. (You probably know the expression about assuming)
Actually, net neutrality matters to me, I don’t want to pay much more to use some subsets of Internet.
No I am not a Kid ;D ;D…
I have a very sound plan about how I will proceed…and I think this forum is not for kidding you all…I am quite confident about how I will implement it…
70 - 80% :
Yeah, sorry, it’s impossible.
As Riven already said most of the stuff you see in your browser is already compressed anyways. What if you actually download a large zip file or something? There is no way to compress that down 70 - 80%.
Source: tried to zip a zip file when I was young.
Tell us once you achieved what you said. It’s hard to believe what you are saying.
That’s actually pretty cool but works on the premise that you have to surf using a proxy. Also it’s not lossless (not that one would actually care most of the time). Still pretty good. It doesn’t fix the zip-file problem either ;D
Anyway OP claimed 70-80% so I’m waiting.
I don’t pay any extra for data usage and I only use a round-off error amount of my bandwidth (fiber optic). I imagine that most people in so-called “developed” nations that care are in the same boat.
Last time I had to deal with pricing based on my (95) percentile of bandwidth usage, was for a dedicated server. Interesting to see such pricing schemes reached the consumer market.
Since many years I have a flatrate, e.g. fixed cost per month. There is a data volume cap, but I never even came close, so I don’t care about that.
Regarding cour compression claim - I don’t think you can reach 70 to 80% compression. Images (gif, png, jpeg) are already compressed, and cannot be shrunk a lot anmyore. Usually the gain is only a few percent, even with quite sophisticated compression on top of the already compressed image data.
Zip files and other archive formats are the same, already compressed and not likely to give gains in the range of 70 to 80%.
That means, the bulk of data transferred is already compressed.
On top of that, HTTP 1.1 offers gzip compression for content, so many web pages you open will be transferred compressed already, and you’ll again face the problem that a compression layer on top of that is not efficient.
Encrypted data like https transfers is also hard to copmpress, because it looks like random data to the compressor.
Briefly: I don’t think you can even come close to your claimed 70 to 80% compression on transferred data, becuase the bulk of thw data transferred is already compressed or hard to compress.