Thanks for the response. I should have clarified further. See inline below/
> If we queue each request and send it after receiving the response for the
> previous one, we should be okay.
[Henrik]How would that make you do okay?
---> I meant that there is no problem in matching request to response if
they are "sequenced" to the server as one transaction after another.
> How will this work for HTTP progressive
> download videos that support "seek streaming" (pseudo-streaming) - The
> first
> request will result in server sending the video file (.swf file) but the
> client can send a HTTP request with a different offset (either using range
> requests or by using URLs like YouTube). When Squid sends out the second
> request to the server, how does it match the incoming bytestream to the
> actual request ? How does this get addressed for caching and non-caching
> scenarios when squid gets deployed as a proxy ?
[Henrik]It matches the response to the request, just as done for any other
request. No difference.
-----> Isn't it impossible to match the response to the request - First
request to the server is to start sending the video file - Let's say this
maps to TCP fragment 1 through 1000 (assuming that the video file is 536000
bytes) - Before the entire video is sent, client sends a request (HTTP range
request or separate URL with the offset embedded) to start sending from the
middle of the video (client does a "fast forward"). Squid has to send this
to the server before receiving the complete response to the original HTTP
request. If the server hasn't sent *all* of the original video, it'll
transmit starting from the location specified in the request. Squid could
now receive TCP fragments from the original stream followed by TCP fragments
from the "mid-video" section. There is no way to identify (and cache) the
"mid-video" section separately. This makes it hard to cache segments sent in
response to range requests. This is the issue I was discussing.
Regards
Henrik
Free Embedda
-- View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/Persistent-Server-connections-pipelining-and-matching-responses-tp2540989p2547693.html Sent from the Squid - Users mailing list archive at Nabble.com.Received on Mon Sep 20 2010 - 21:12:49 MDT
This archive was generated by hypermail 2.2.0 : Tue Sep 21 2010 - 12:00:03 MDT