[tor-dev] connection_edge_process_relay_cell(): data cell dropped, unknown stream

[Fabian Keil]

Roger Dingledine <arma at mit.edu> wrote:

> On Wed, Sep 21, 2011 at 10:20:22PM +0200, Fabian Keil wrote:

> > I assume it can take several seconds for the exit relay to stop sending
> > data and the Tor client has to continue reading from the stream to keep
> > the circuit usable. Is that correct?
> 
> Yes. The client closes the stream, and sends an end cell toward the
> exit. Meanwhile, the exit sends stuff toward the client. Because of that
> pesky "the intermediate hops can't look inside the circuit" feature,
> there's nothing that the relays can do to realize that these cells aren't
> wanted anymore.
> 
> This behavior is particularly unfortunate when the client is on a modem,
> asks for a page, gives up on the page, asks for another one, and then
> the first one fills his pipe for a little while, making the second one
> not work either.

In my case the feed reader seems to request most images twice,
aborting the first request prematurely. I'm not sure how much
this actually affects the performance.

> I guess we could kill the whole circuit that the stream was on, which
> would propagate forward and meet up with the data cells propagating back.
> But that wouldn't work in situations where you wanted the circuit to
> stick around, e.g. for its other streams.

Maybe I should experiment with that.

> > Is it intended behaviour for the Tor client to forget a stream
> > id before the stream is actually closed on the remote end?
> 
> Yes. No good can come of remembering the streamid just so we can know
> that we meant to throw the cells away. Unless you have something in mind?

Nope. I just wasn't sure if my interpretation of the logs was correct,
and from the code it wasn't obvious to me in what kind of situation
unknown cells are to be expected.

Thanks for the explanation, Roger.

Fabian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20110922/7e0791d5/attachment.pgp>