From: Ray Olszewski <ray@comarre.com>
To: linux-newbie@vger.kernel.org
Subject: Re: filtering .mp3 packets
Date: Fri, 29 Apr 2005 08:51:19 -0700 [thread overview]
Message-ID: <427257F7.7040800@comarre.com> (raw)
In-Reply-To: <4b0d6e0d0504290824427d7beb@mail.gmail.com>
joy merwin monteiro wrote:
> Hi,
>
> Was going through lartc HOWTO and it says that Linux
> can throttle b/w TO certain computers on the network....
> this can assure that all computers get the same amount of b/w
> p2p or no p2p.......
> how 'bout it, setting some amount of bandwidth to each user,
> so he cannot receive or send more than his quota
> and hose the network.......
[...]
Whether this is a good solution or not depends on what the perceived
problem is.
If the issue is file sharers tying up bandwidth to the Internet, this is
an excellent approach. It will limit all heavy users indiscriminately,
though, so someone who (say) does a network-based upgrade of his or her
Linux host (an "apt-get upgrade" in Debian terms, or the equivalent for
other distros) or downloads ISO images of Linux-distro CDs will be
limited in the same way as someone doing a lot of music downloads.
If the issue is preventing use of the Internet connection to download
unauthorized copies of copyrighted materials, then this approach is
probably not sufficiently targeted to accomplish what the original
poster requested. It has the "false positive" problem in spades.
If the issue is inhibiting on-LAN exchanges of unauthorized copies of
copyrighted materials ... well in that case, this entire discussion's
focus on solutions at the router level is completely misplaced. If that
is the perceived problem (in a college setting, I can easily imagine it
being so, especially of the LAN provides service to dorm rooms), the
solution needs to involve a heavy dose of on-LAN traffic sniffing. Even
talking about that approach requires less abstraction from a particular
LAN implementation then we have had here so far.
Whatever the case, this idea does have the advantage, relative to other
approaches that have been discussed in this thread, of being based on
Linux kernel capabilities that actually exist, not extensions that
"should be easy" but that, in fact, have not been done, or (I suspect)
even looked at closely by anyone with the technical expertise actually
to implement them.
BTW, lest I be misinterpreted, I am not trying to present an argument
for or against actually doing any particular kind of content filtering.
I am only trying to think aloud about the technical issues involved in
implementing solutions to various desires for control of network use.
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
next prev parent reply other threads:[~2005-04-29 15:51 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-25 11:27 filtering .mp3 packets William Stanard
2005-04-25 16:56 ` Ray Olszewski
2005-04-26 11:36 ` John T. Williams
2005-04-27 14:15 ` J.
2005-04-27 15:22 ` simon
2005-04-27 19:51 ` J.
2005-04-27 22:57 ` John T. Williams
2005-04-28 0:39 ` Ray Olszewski
2005-04-29 3:05 ` joy merwin monteiro
2005-04-29 11:43 ` Stephen Ray
2005-04-29 15:24 ` joy merwin monteiro
2005-04-29 15:51 ` Ray Olszewski [this message]
2005-04-29 23:39 ` joy merwin monteiro
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=427257F7.7040800@comarre.com \
--to=ray@comarre.com \
--cc=linux-newbie@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox