All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Frischknecht peter@empoweringsolutions.com
To: lartc@vger.kernel.org
Subject: [LARTC] Napster Upstream Bandwidth Control
Date: Sat, 13 Jan 2001 17:05:25 +0000	[thread overview]
Message-ID: <marc-lartc-98373940416876@msgid-missing> (raw)

<PRE>Okay here it goes.

I have been fighting this one for a while, and I would like to know if there
is anybody else out there who shares my pain.

I run medium size LANs (150-450 nodes) for apartment complexes and provide
them with internet access.  You can bet your hat on what consumes(ed) most
of may bandwidth: Napster.

I have been very successfull in curbing all of the DOWNLOAD speeds, but I am
having a hard time with the UPLOADS.
So you say: just block any NEW, INBOUND connections...  well, unless you
have pleyed with it, you would not know that it isn't that simple.  You see,
when an internal user has his Napster shared port set to 6699 (an example).
Upon a logon to the Napster servers, any outside user who wants to get songs
from my internal user has to stablish a direct connection to my internal
user.  This scenario I can prevent.
However, if the internal user has his Napster port set to 0, the Napster
server will broker the song upload so that it actualy initiates in my
network.  Specificaly, by observing the logged pakets of a file transfer,
this is what happens:

In-User is logged on to Napster:8888 with shared port 0.
Out-User is logged on to Napster:8888 with shared port 6699.
Out-User wants a file from In-User.
Out-User tells Napster:8888: go tell In-User.
Napster:8888 tells In-User: Out-User:6699 wants file x.
In-User opens a new socket and contacts Out-User:6699.
Out-User now has a TCP connection to In-User and can receive file x.

Well...  What now?
How am I supposed to stop that?
Some may say: just slow it down enough so that it is unusable.
The problem is that if I am DOWNLOADING a song from an Out-User:6699, I have
to send an acknowledgement packet that has to fight traffic with songs being
uploaded.  The final effect is that I will get slow downloads as well.

I don't claim to know everything about bandwidth control, but I have been
having great success with packet Marking (iptables) and tc.  It has resolved
99% of all my bandwidth issues.  My setup is roughly 4 months old and I feel
confortable enough with it to start creating a Web Interface  for my
purposes.

I would greatly appreciate any ideas/comments/suggestions... heck I would
even like getting flamed if it led me to some solution.

Peter Frischknecht





</PRE>

             reply	other threads:[~2001-01-13 17:05 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-01-13 17:05 Peter [this message]
2001-01-13 17:15 ` [LARTC] Napster Upstream Bandwidth Control bert
2001-01-13 17:38 ` Peter

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=marc-lartc-98373940416876@msgid-missing \
    --to=lartc@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.