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

On Fri, 6 Aug 1999, Joe Ramey wrote:

> A few days ago I reported a problem when using the RealPlayer client
> to access realaudio content through a busy squid 2.2 proxy. The
> problem only shows up when the squid 2.2 proxy is very busy. If the
> squid 2.2 proxy is lightly loaded, or if we use a very busy squid
> 1.1.22 proxy, we can access realaudio through the proxy just fine.
> We're running all this on Solaris 2.5.1 on SPARC hardware.
>
> We did some more experimentation with this. From what I can tell,
> this is a problem in the RealPlayer client, or perhaps even in the
> RealPlayer protocol for accessing realaudio content through HTTP.
> However, I'm still not 100% sure why this is happening.
>
> It looks like the RealPlayer client basically does the following when
> accessing realaudio through http: first it does a POST to the
> requested URL. It sends some long hex number (apparently random?) as
> the input to the POST. It keeps the POST open, since it will be
> sending more data to the POST later in the session. Then it does a
> GET of the URL with that long hex number appended. I guess they use
> that hex number as some kind of session identifier so that the POST
> and GET can be associated with each other. Looks like they use the
> GET connection to receive the data from the realaudio web server, and
> they use the POST to send back some kind of feedback info. Not sure
> what. Anyway, here's the key: if you send the GET *before* the POST,
> then the server won't send you the audio data. You have to send the
> POST first, then the GET.
>
> 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).

I believe that this could happen. Squid doesn't really
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.

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

Duane W.
Received on Tue Aug 10 1999 - 12:46:53 MDT