? Too many connections from your IP address ?

I need to know what is recommended practice for <quitting>.

When I started years ago [with BBS] I used to always 'politely'
<log off>; and I still do `quit` with telnet, because I know how to.

But as I had to hack the source-code of my mail-client when my
ISP [and the industry in general] introduced send authorisation,
and as I just pulled-the-plug instead of finding out how to
<ppp-off>, my hacked USEnet-client is finally getting a warning
[apparently from the server]:
"Too many connections from your IP address
sending 400 Too many connections from your IP address"

IIRC I needed to modify the news-client, because the original
server became slow and I had to get one that required password
login, as USEnet degenerated towards blogs.

It occurred to me, that in modifying and testing the code, I had
never considered the log-off/disconnect aspect; and that when I
eg. fetch 8 news articles via 8 lines of a script, each <fetch command>
doesn't <quit>, so eventually the server see 8 connections from my IP.

Before I crack open the source code files, I'd like to know the
theory of what I should be looking for, re. <quitting>.
Oh, I've just realised that I can read the RFCs which I've got
[here in my 3rd world location, going 4th].

PS. I now also remember <FtpClose>.
Some reasons why I don't use standard/consumer clients are:
* I know it's a lie that "life is better with coke";
* I've got expensive dialup facilities;
* surfing is 'going nowhere and just waiting to fall off', so
I seldom use a full-featured-browser, but instead have
scripts to:
= fetch the list of URLs in file1 to Append-file2
= fetch google-search(args) to fileG
= ...etc.
* MAINLY: being without the facility that only ETHOberon
gives me, of having multiple text-frames visible on the same
screen, so that I can edit, cutNpaste, colour text stretches, etc.
of emails, USEnet, logFiles..anyFiles,
is like trying to tie your shoe-laces while wearing boxing-gloves.

So don't suggest that I update to the latest monster all
purpose app., because you were all wrong when you followed the
herd, in believing that you could live on your credit cards.

Thanks,

== Chris Glur.

On Wed, 2011-11-02, (E-Mail Removed) wrote:
> I need to know what is recommended practice for <quitting>.

It's a bit unclear to me what you're talking about -- you're
mentioning a lot of different things.

If you're talking about the NNTP protocol, best practice is something
like

- reuse one connection for at least minutes
- but tolerate that the server disconnects you if you're idle
- use the QUIT command to quit

For more details, see RFC 3977.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

On Wed, 02 Nov 2011 02:24:14 +0000, Jorgen Grahn wrote:

>> I need to know what is recommended practice for <quitting>.
>
> It's a bit unclear to me what you're talking about -- you're mentioning
> a lot of different things.

He's a known troll, and an idiot.

Best to just ignore the dipshit.


--
"Ubuntu" -- an African word, meaning "Slackware is too hard for me".
"Bother!" said Pooh, as Piglet pulled out the Anal Intruder.
Usenet Improvement Project: http://twovoyagers.com/improve-usenet.org/
Thanks, Obama: http://brandybuck.site40.net/pics/politica/thanks.jpg

(E-Mail Removed) wrote:
> It occurred to me, that in modifying and testing the code, I had
> never considered the log-off/disconnect aspect; and that when I
> eg. fetch 8 news articles via 8 lines of a script, each <fetch command>
> doesn't <quit>, so eventually the server see 8 connections from my IP.

In your situation, does each "fetch" do a complete connect + authorise +
get_article + disconnect? Or is there a single connect + authorise at the
top with each fetch utilising that session channel? If it's the former,
then the error message may be complaining about the number of sessions
in a given time rather than the number of concurrent sessions.

Bear in mind that when you disconnect the TCP stream, the far end gets
notification and is expected to do something about it, so there shouldn't
be resources hanging around on the server side for connections that you
have closed. The QUIT command in NNTP-land is a politeness to say
"I've finished thank you". Just like with SMTP, it shouldn't really
be necessary.

Chris

In article <slrnjb1aed.1bk.grahn+(E-Mail Removed)>, Jorgen Grahn <grahn+(E-Mail Removed)> wrote:

> On Wed, 2011-11-02, (E-Mail Removed) wrote:
> > I need to know what is recommended practice for <quitting>.
>
> It's a bit unclear to me what you're talking about -- you're
> mentioning a lot of different things.
>
If you included the part which confuses you, one could focus.

> If you're talking about the NNTP protocol, best practice is something
> like
>
> - reuse one connection for at least minutes
> - but tolerate that the server disconnects you if you're idle
> - use the QUIT command to quit
>
I don't want to dig out the code now but consider the following:
"ipNews.ArtGrpNo alt.os.linux.slackware 16497" runs
[this is my actual coe-syntax, directly pasted here];
I'll assume that my client doesn't start the next <fetch article>
until <alt.os.linux.slackware 16497> has finished d/l-ing,
because I naturally concentrated on 'what I get'.
But what about the server, if I then run
"ipNews.ArtGrpNo comp.os.linux.networking 5942"?
Does this open a further "connection" [using the wording of the server]?

If the NNTP-server could handle the possibility of the same IP
requesting a further article while the first article was still being
delivered, which my client does NOT do; then perhaps the protocol
was designed for the client to acknowledge the receipt, so that
the server, does NOT open a new connection for the next/new
request.

What else does the server signal
"Too many connections from your IP address " ?

> For more details, see RFC 3977.
>
Thanks.

Jorgen Grahn <grahn+(E-Mail Removed)> writes:
> (E-Mail Removed) wrote:

>> I need to know what is recommended practice for <quitting>.
>
> It's a bit unclear to me what you're talking about -- you're
> mentioning a lot of different things.
>
> If you're talking about the NNTP protocol, best practice is something
> like
>
> - reuse one connection for at least minutes
> - but tolerate that the server disconnects you if you're idle
> - use the QUIT command to quit
>
> For more details, see RFC 3977.

The important point is that the connection must be closed when its
finished with; whether this is done via QUIT (the "preferred method",
though as far as I can see this is just arbitrary bureaucracy) or
closing the connection directly is secondary.

--
http://www.greenend.org.uk/rjk/

In article <(E-Mail Removed)>, Richard Kettlewell <(E-Mail Removed)> wrote:

> Jorgen Grahn <grahn+(E-Mail Removed)> writes:
> > (E-Mail Removed) wrote:
>
> >> I need to know what is recommended practice for <quitting>.
> >
> > It's a bit unclear to me what you're talking about -- you're
> > mentioning a lot of different things.
> >
> > If you're talking about the NNTP protocol, best practice is something
> > like
> >
> > - reuse one connection for at least minutes
> > - but tolerate that the server disconnects you if you're idle
> > - use the QUIT command to quit
> >
> > For more details, see RFC 3977.
>
> The important point is that the connection must be closed when its
> finished with; whether this is done via QUIT (the "preferred method",
> though as far as I can see this is just arbitrary bureaucracy) or
> closing the connection directly is secondary.
>
> --
I speculate that:
= the correct procedure, to economise on inet resources,
is to actively close the connection, instead of relying on
time-out.
= when I hacked the code, i considered it to be ok, once
I'd received the d/l-ed article; but the protocol requires
a further 'signal' to notify the server that the send-article
has been successfully completed.
= while the server is waiting for this missing confirmation,
it receives another/several requests from the same IP, and
it has been appropriately programmed to identify such
multiple requests from a single IP as <an attack>.

What do the network experts say?

== Chris Glur.

In article <(E-Mail Removed)>, Chris Davies <chris-(E-Mail Removed)> wrote:

> (E-Mail Removed) wrote:
> > It occurred to me, that in modifying and testing the code, I had
> > never considered the log-off/disconnect aspect; and that when I
> > eg. fetch 8 news articles via 8 lines of a script, each <fetch command>
> > doesn't <quit>, so eventually the server see 8 connections from my IP.
>
> In your situation, does each "fetch" do a complete connect + authorise +
> get_article + disconnect? Or is there a single connect + authorise at the
> top with each fetch utilising that session channel?
I don't know yet, without swapping disks and rebooting; and was hoping for
a simple confirmation/explanation before bringing out the heavy guns.
> If it's the former,
> then the error message may be complaining about the number of sessions
> in a given time rather than the number of concurrent sessions.
>
Why would it do that? When I noticed that it seemed to show <disconnected>
after 3 fetches, I though that I may have a quota per logon session.
But the servers message is verbatim:
"Too many connections from your IP address".
Isn't that a typical symptom of an attack?

> Bear in mind that when you disconnect the TCP stream, the far end gets
> notification and is expected to do something about it, so there shouldn't
> be resources hanging around on the server side for connections that you
> have closed.
The opposite of this is what I suspect.

> The QUIT command in NNTP-land is a politeness to say
> "I've finished thank you". Just like with SMTP, it shouldn't really
> be necessary.
>
> Chris

Perhaps I need to draw a picture!
aaxxxxxxxxx
zzzbbxxxxxxx
zzzzzzzccxxxxx

a,b,c is the time to send the 1st, 2nd, 3rd articles

x is the time after the articles have been received, but the <connection
has not be 'quit' yet>.

So when c starts, there are 3 "connections from your IP address".

And typically I've got 8 <requests> in my script, which get sent
off sequentially.

I'm surprised that I'm having such difficulty in explaining this.

(E-Mail Removed) writes:
> Richard Kettlewell <(E-Mail Removed)> wrote:
>> Jorgen Grahn <grahn+(E-Mail Removed)> writes:
>>> (E-Mail Removed) wrote:
>>>> I need to know what is recommended practice for <quitting>.
>>>
>>> It's a bit unclear to me what you're talking about -- you're
>>> mentioning a lot of different things.
>>>
>>> If you're talking about the NNTP protocol, best practice is something
>>> like
>>>
>>> - reuse one connection for at least minutes
>>> - but tolerate that the server disconnects you if you're idle
>>> - use the QUIT command to quit
>>>
>>> For more details, see RFC 3977.
>>
>> The important point is that the connection must be closed when its
>> finished with; whether this is done via QUIT (the "preferred method",
>> though as far as I can see this is just arbitrary bureaucracy) or
>> closing the connection directly is secondary.
>>
> I speculate that:
> = the correct procedure, to economise on inet resources,
> is to actively close the connection, instead of relying on
> time-out.

As stated above: the connection must be closed when you are finished
with it.

> = when I hacked the code, i considered it to be ok, once
> I'd received the d/l-ed article; but the protocol requires
> a further 'signal' to notify the server that the send-article
> has been successfully completed.

The protocol is well documented; no need to speculate about it.

> = while the server is waiting for this missing confirmation,
> it receives another/several requests from the same IP, and
> it has been appropriately programmed to identify such
> multiple requests from a single IP as <an attack>.
>
> What do the network experts say?

They say "not responsible for advice not taken".

--
http://www.greenend.org.uk/rjk/

> In article <(E-Mail Removed)>, Chris Davies <chris-(E-Mail Removed)> wrote:
>> [...] the error message may be complaining about the number of sessions
>> in a given time rather than the number of concurrent sessions.

(E-Mail Removed) wrote:
> Why would it do that? When I noticed that it seemed to show <disconnected>
> after 3 fetches, I though that I may have a quota per logon session.
> But the servers message is verbatim:
> "Too many connections from your IP address".
> Isn't that a typical symptom of an attack?

Why shouldn't it do that? There are four things that I would consider
measuring per user account if I was serious about limiting resource usage:

- concurrent connections
- total connections per time interval
- bandwidth (across all concurrent connections)
- traffic transferred per time interval


> Perhaps I need to draw a picture!
> aaxxxxxxxxx
> zzzbbxxxxxxx
> zzzzzzzccxxxxx

> a,b,c is the time to send the 1st, 2nd, 3rd articles

> x is the time after the articles have been received, but the <connection
> has not be 'quit' yet>.
>
> So when c starts, there are 3 "connections from your IP address".

> And typically I've got 8 <requests> in my script, which get sent
> off sequentially.

It doesn't really matter that you're firing off the requests sequentially
if the server sees the connections concurrently. You might want to
consider changing your process flow to this:

connect auth fetch1 fetch2 fetch3 ... fetch8 disconnect
----time--->


> I'm surprised that I'm having such difficulty in explaining this.

It's because you're not being clear enough. I specifically asked a
question relating to concurrency and you're earlier - in this same
message - said that you don't know the answer (without swapping disks
and rebooting).

I must admit, though, that if you're hitting resource limits from your
upstream it might be worth running something like leafnode2. You would
point your application at your local leafnode2 NNTP server and the whole
problem gets side-stepped neatly.

Chris