Re: more info on RealPlayer + squid 2.2 problem (under Solaris 2.5.1)

   Date: Tue, 10 Aug 1999 12:45:03 -0600
   From: Duane Wessels <wessels@ircache.net>
   cc: squid-users@ircache.net
   Content-Type: TEXT/PLAIN; charset=US-ASCII

   On Fri, 6 Aug 1999, Joe Ramey wrote:

> Now, it appears that when the squid 2.2 is real busy, sometimes the
> transactions get out of order. It looks like the realplayer thinks it
> is sending the POST first, then the GET (and if I use `snoop' to watch
> the communication between the RealPlayer and the squid I do see the
> POST come by before the GET) , but the squid debug info shows that the
> squid first reads and sends the GET request, and then it reads and
> sends the POST request (and I can see the same thing via `snoop').
> Again, this only happens when the squid is real busy, and only on
> squid 2.2 (not 1.1).

   guarantee that two request recieved in a short amount of time
   are sent in the same order.

   Seems like the client should wait for some kind of ack on the
   POST connection before sending the GET request.

Yep, I agree with you. I think their protocol is a little `broken',
at least WRT how they use it over HTTP.

   The easiest hack that I can think of is to use a redirector
   to "sleep" the GET request for a short amount of time.

Thanks, that's a good idea. I hadn't thought of that. It might be a
pretty good workaround. I'll take a look at doing this.

I did just a bit more debugging on this and the client seems even
weirder than I thought before. Looks like the client first opens the
GET connection, then opens the POST connection, then writes a request
on the POST connection, and writes a request on the POST connection.
So, it seems likely that squid might accept the two connections one
after another in the same accept loop and so the POST would get a
higher numbered FD than the GET. Then, if both had data to read at
about the same time, squid would read from the lower numbered FD first
(doesn't it basically go through all ready FDs in numerical order?).

I also learned that I can easily reproduce this problem on a lightly
loaded squid simply by using the Solaris 2 `truss' command to trace
all the system calls in the squid daemon. I guess `truss' slows it
down enough to make

I still don't understand why we aren't seeing this problem with squid
1.1. That's one part of the puzzle that I'd still like to figure out,
since it would be nice if there was some simple thing that I could
change in squid 2 to make it work like squid 1 does, at least as far
as this problem goes.

Thanks for your reply! I'll try out the workaround you suggested.

Joe
Received on Tue Aug 10 1999 - 12:55:19 MDT