stream status events

[Mike Perry]

Thus spake Robert Hogan (robert at roberthogan.net):

> Stream status events for reverse resolve requests for which Tor has a cached 
> answer look like this:
> 
> 650 STREAM 6 NEWRESOLVE 0 64.4.33.7:0
> 650 STREAM 6 FAILED 0 REVERSE[64.4.33.7]:0
> 650 STREAM 7 NEWRESOLVE 0 64.4.33.7:0
> 650 STREAM 7 FAILED 0 REVERSE[64.4.33.7]:0
> 
> The stream 'fails' because there is never a need to create it. The spec is a bit 
> unclear on this point but I think all streams deserve a CLOSE event. Or 
> is 'FAILED' considered sufficient?
> 
> I can allow a CLOSE event by doing:
> [snip]
>  
> but maybe it's the spec that needs to be clarified. A short note stating which 
> events should be expected for all streams maybe.

I agree that all streams should get CLOSEs. In fact, I don't think it
makes any sense at all to call a stream FAILED simply because we
handled it locally.. 

My vote is that the FAILED message should be dropped entirely here,
because it will mess with TorFlows ability to gather accurate
statistics on stream reliability.

Do you happen to know if there are other cases where this sort of
thing can occur?


-- 
Mike Perry
Mad Computer Scientist
fscked.org evil labs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20080715/654804fe/attachment.pgp>