[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: kio_http, persistent connections
From:       Rik Hemsley <rik () kde ! org>
Date:       2001-06-04 20:31:21
[Download RAW message or body]

#if Waldo Bastian
> > This happens when kio_http has not yet retrieved the full response from
> > the server.
> 
> > According to RFC2616, clients should simply pipeline requests without
> > waiting for a response from the server.
> 
> No, they _may_ pipeline requests. It doesn't say they _should_. Pipelining is 
> currently not supported by the io-slave architecture which handles requests 
> one by one.

Ah yes, sorry, RFC language :) _IMO_ they should pipeline :)

> io-slaves do not know if more requests will follow.

Yes. This is a shame, but I can't think of a way around it.

> There should be no more than about 4 concurrent open connections to the same 
> host. How many kio_http processes do you have running? How many open network 
> connection do you have?

Looking at my home page, I see 5 kio_http processes and 5 open network
connections. 2 would be better :)

> > I think that the best solution would simply be to ensure that no
> > more than 4 connections are made to one host.
> 
> That should already be the case. Are you sure your server correctly detects 
> connections being closed?
> 
> "Clients and servers SHOULD both constantly watch for the other side of the 
> transport close, and respond to it as appropriate."

Well, it should ...

connect
(
 &(d->socket),  SIGNAL(connectionClosed()),
 this,          SLOT(slotConnectionClosed())
);

..

  void
Server::slotConnectionClosed()
{
  finished();
}

..

  void
Server::finished(bool flush /* default is true */)
{
  if (flush)
    d->socket.flush();

  d->socket.close();

  [...]
}

(d->socket is a QSocket)

Hmm, perhaps by accident calling finished() in slotConnectionClosed()
is actually emitting finished(). I don't see how that can happen, but
I'll change the names to be sure.


> > After a page with a few graphics has been accessed, I will have 4
> > connections waiting 60 seconds to timeout, so the connection pool will
> > still be artificially filled, but this is better than > 4 connections,
> > at least.
> 
> You could reduce your timeout.

Indeed. I probably should, but I don't think that will solve the problem
of so many connections being made by kio_http.

> > Perhaps I will have to decide that persistent connections are a bad
> > idea, due to the way that kio_http makes connections (and fails to
> > disconnect when it should.)
> 
> I am not aware that they _should_ disconnect at any specific time.

Well, again here's the problem of predicting the future and knowing
that the current page is finished loading, plus that the user isn't
going to click on a link. Hmm :)

Rik

[prev in list] [next in list] [prev in thread] [next in thread]