clientReplyContext::replyStatus and proxy_keepalive

[Alex Rousskov]

Hello,

If you understand clientReplyContext::replyStatus, please see if you
can help me with the following problem.

Background: I am making aborted POSTs to work with the new BodyPipe.
Under certain ICAP failure conditions, the client side needs to produce
an error response. We did not have any code for that case.

I found disabled "#if ICAP_HARD_ERROR" code inside
ClientHttpRequest::abortAdapting, removed the yet-unsupported errno
argument, and moved the code outside the if-statement. That wonderful,
albeit mysterious, piece if code seems to produce an error just fine.
The error is sometimes generated before the entire POST body is read and
discarded.

Problem: The following piece of client_side_reply code appears to be
sometimes confused by the client-side produced error and/or my other
bugs. It returns STREAM_UNPLANNED_COMPLETE, causing various problems on
the client_request side (e.g., entering "closing" state twice).

> clientStream_status_t
> clientReplyContext::replyStatus()
> {
> ...
> if (!done) {
> debug(88, 5) ("clientReplyStatus: closing, !done, but read 0 
> bytes\n
> return STREAM_FAILED;
> }
> 
> if (!http->gotEnough()) {
> debug(88, 5) ("clientReplyStatus: client didn't get all it 
> expected\
> return STREAM_UNPLANNED_COMPLETE;
> }
> 
> if (http->request->flags.proxy_keepalive) {
> debug(88, 5) ("clientReplyStatus: stream complete and can 
> keepalive\
> return STREAM_COMPLETE;
> }
> 
> debug(88, 5) ("clientReplyStatus: stream was not expected to 
> complete!\n
> return STREAM_UNPLANNED_COMPLETE;

Could somebody please explain the logic here? Specifically, I do not
understand why proxy_keepalive flag is required to get a STREAM_COMPLETE
result. I am getting STREAM_UNPLANNED_COMPLETE (from the last return
statement) because the request apparently does not have that flag set.
What does it mean to have a "complete stream" and why do I need a
proxy_keepalive flag with that?

A related question: Is replyStatus() expected to work correctly when the
connection is in a closing state?

Thank you,

Alex.

Re: clientReplyContext::replyStatus and proxy_keepalive

[Robert Collins]

On Wed, 2007-02-07 at 17:42 -0700, Alex Rousskov wrote:
> Hello,
> 
>   If you understand clientReplyContext::replyStatus, please see if you
> can help me with the following problem.
> 
...
> Could somebody please explain the logic here? Specifically, I do not
> understand why proxy_keepalive flag is required to get a STREAM_COMPLETE
> result. I am getting STREAM_UNPLANNED_COMPLETE (from the last return
> statement) because the request apparently does not have that flag set.
> What does it mean to have a "complete stream" and why do I need a
> proxy_keepalive flag with that?
> 
> A related question: Is replyStatus() expected to work correctly when the
> connection is in a closing state?
> 
> Thank you,

I'll page this in and peek at it after work today - in 4-5 hours.

Cheers,
Rob
-- 
GPG key available at: .


signature.asc
Description: This is a digitally signed message part

Torrent web cache.

[Mat Hounsell]

I think I have an idea y'all might like.

http://www.pbs.org/cringely/pulpit/2007/pulpit_20070202_001566.html

Robert Cringely wrote about the problems ISP are facing with torrent traffic. 
Basically alll that traffic to the real Internet is costing them money.

Thinking about I realised that it was a similar problem to images ladden sites 
in the 14.4K days, and still today.

They solve that problem with Squid. That wonderful free open source web proxy 
cache.

They can solve the torrent problem the same way. In fact the design of torrent 
makes it easier.

All they have to do is intercept all get requests for application/x-bittorrent 
and
*.torrent url.

Then their torrent cache can start several torrent clients and get the file too.

From then on their torrent cache can act as several seeding torrent peers.

The protocol would mean most of the ISP customer's subsequent request would 
come from the cache.

What is more, it would be simple and efficient to deploy many beige box torrent 
caches.

I am not familiar enough with the torrent protocol, squid, or to be honest 
server programming to start this by myself.

Interested?



Send instant messages to your online friends http://au.messenger.yahoo.com

Re: Torrent web cache.

[Adrian Chadd]

On Tue, Feb 06, 2007, Mat Hounsell wrote:
> I think I have an idea y'all might like.

> What is more, it would be simple and efficient to deploy many beige box 
> torrent caches.
> 
> I am not familiar enough with the torrent protocol, squid, or to be honest 
> server programming to start this by myself.

I should've replied publicly. :)

Its what I'm trying to achieve by first fixing up the Squid internals. My aim is
to have the Squid internals up to scratch to handle the large, sparse p2p type
content with all the QoS/ACL magic Squid already provides. I'd also like to
build in caching hierarchies to allow people to peer proxies in groups
to share p2p content, rather than trying to peer lots of little files.

Join #squiddev on freenode and talk to us about it sometime.
(And let me know which city in Australia you're in; i'm in Perth.)




Adrian