- From: Fred Baker <fred@cisco.com>
- Date: Thu, 25 Jun 2009 17:37:37 -0700
- To: Henrik Nordstrom <henrik@henriknordstrom.net>
- Cc: leighton@mail.eecis.udel.edu, Mark Nottingham <mnot@mnot.net>, ietf-http-wg@w3.org, amer@cis.udel.edu, prenatar@cisco.com
I would first ask how often this is an issue - I certainly stop http downloads from time to time, but it's not a primary behavior. It also seems to me that the problem is self-correcting. If I have N potential streams and have opened M file downloads, of which I want to stop one, I can redirect the errant stream to /dev/null until the other downloads complete. At that point, it is either done or not done. If it completed in the meantime, I lost 1/M of my available rate during the event but nothing permanent happened. If it is not complete, I can kill the session and open a new one. And btw, since I will change the cookie, I could even reopen it using the same port number. On Jun 25, 2009, at 5:18 PM, Henrik Nordstrom wrote: > tor 2009-06-25 klockan 16:53 -0400 skrev leighton@mail.eecis.udel.edu: > >> Can you elaborate on your comment about trying to map multiple >> pipelined >> TCP connections to a single SCTP association not working out well? >> Thanks. > > Sorry, should have said multiple TCP connections vs a single SCTP > association. It's not related to pipelining but the differences in > transport level (in HTTP terms) signaling between multiple TCP > connections and a single SCTP association. > > The main problem there is selective stream cancellation by the client. > > If all pending requests is to be canceled together then this is not an > big issue, just tear down the SCTP association and be done with it. > But > if you need to more selectively cancel requests (i.e. a big download > you > accidently started) without breaking the other concurrent pending > requests then things get a little trickier.. > > In the TCP case (non-pipelined) the client just closes that TCP > connection which terminates that requests with no impact on the other > requests. > > Regards > Henrik >
Received on Friday, 26 June 2009 00:38:22 UTC