public inbox for linux-newbie@vger.kernel.org
 help / color / mirror / Atom feed
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

  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