From: bert hubert ahu@ds9a.nl
To: lartc@vger.kernel.org
Subject: [LARTC] Napster Upstream Bandwidth Control
Date: Sat, 13 Jan 2001 17:15:24 +0000 [thread overview]
Message-ID: <marc-lartc-98373940416877@msgid-missing> (raw)
In-Reply-To: <marc-lartc-98373940416876@msgid-missing>
<PRE>On Sat, Jan 13, 2001 at 12:05:25PM -0500, Peter Frischknecht wrote:
><i> Okay here it goes.
</I>><i>
</I>><i> I have been fighting this one for a while, and I would like to know if there
</I>><i> is anybody else out there who shares my pain.
</I>
Yes, many of us do. Napster is all good and well, and I wouldn't like to
prohibit it, but once it starts using sizeable amounts of your bandwidth,
the fun goes out of it.
><i> Out-User is logged on to Napster:8888 with shared port 6699.
</I>><i> Out-User wants a file from In-User.
</I>><i> Out-User tells Napster:8888: go tell In-User.
</I>><i> Napster:8888 tells In-User: Out-User:6699 wants file x.
</I>><i> In-User opens a new socket and contacts Out-User:6699.
</I>><i> Out-User now has a TCP connection to In-User and can receive file x.
</I>
The problem is that you need to recognize, specifically, outbound napster
connections. Would any connection *to* port 6699 be an outgoing napster
connection?
><i> How am I supposed to stop that?
</I>><i> Some may say: just slow it down enough so that it is unusable.
</I>><i> The problem is that if I am DOWNLOADING a song from an Out-User:6699, I have
</I>><i> to send an acknowledgement packet that has to fight traffic with songs being
</I>><i> uploaded. The final effect is that I will get slow downloads as well.
</I>
You want to have your cake, and eat it :-) Perhaps you can make it really
complicated, and exempt ACK packets from accounting? I expect that the u32
match is up to this. Otherwise, select on large/small packets.
><i> I would greatly appreciate any ideas/comments/suggestions... heck I would
</I>><i> even like getting flamed if it led me to some solution.
</I>
I would really like to find a way that enables you to throttle napster
service, so as to keep it alive, but not kill it.
Regards,
bert hubert
--
PowerDNS Versatile DNS Services
Trilab The Technology People
'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet
</PRE>
next prev parent reply other threads:[~2001-01-13 17:15 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-01-13 17:05 [LARTC] Napster Upstream Bandwidth Control Peter
2001-01-13 17:15 ` bert [this message]
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-98373940416877@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.