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

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'm not sure if this problem (getting the requests out-of-order) is
happening in the Solaris 2.5.1 kernel somehow or if it's happening
inside of squid. I've looked at the connection accepting a bit but so
far can't completely explain what is happening. Any ideas?

Joe
Received on Fri Aug 06 1999 - 16:30:03 MDT