Re: more on thedj.com

[I'm coming a little late to this...]

Matthew Petach <mattp@Internex.NET> said:
} TheDJ uses RealAudio, which requires their own proprietary proxy.
} No, it will not work with Squid, and never will until RealAudio is
} willing to release the details of their data stream. You will need
} to purchase a copy of the RealAudio proxy if you wish to allow your
} users to stream audio through your network.

This is being unfair to PN. The data encoding is not published, but they
have been very open about publishing the required information about the
control channel to allow people to write proxies etc. I have found them
to be extremely helpful with this sort of thing ever since I spent a few
email messages persuading them to allow me to see the original proxy form
without an NDA so that I could release the RealAudio help app for the
Linux IP masquerading under GPL. They took those comments on board and
ever since they have had the firewall development toolkit available for
download (you just need to fill in a web form).
To summarise PN have been *very* helpful about releasing necessary
information on their protocols without restrictive licensing.

However adding RA proxying into squid is unnecessary and purely bloating
squid for not great gain.

signal@shreve.net said:
} But realaudio doesnt use port 80, and I only proxy port 80. So
} shouldnt that data just go right thru?

Yes it should. However it sounds like thedj have done something strange.
Normally a little control file (typically contains a single pnm: URL)
should be picked up by http which is passed to the RA application which
makes a TCP control connection and a UDP or TCP (selectable) data
connection to the RA server. This should work fine with or without squid
proxying transparent or otherwise.

There are some RA protocol oddities for use when you are completely
firewalled off which work just with HTTP requests, but they are very much
a second best approach (actually they mostly don't work, don't stream etc).

However from what I have gathered about this thread it looks like a
connection is being assumed back to a different port on the connecting box
(as seen by the remote server) - similar effect as to transparent
redirection of an FTP control channel without rewriting the PORT commands.

I guess the basic question is what happens if you explicitly proxy teh
HTTP to the squid rather than using transparent proxy?

signal@shreve.net said:
} So what I gather, is that, as long as I force users to have port 80
} redirected via the cisco to my linux box which runs squid, then
} thedj.com will *never* work? That really sucks.

Its possible - tends to happen when people assume that they can connect
back to the connecting machine on a particular port and it will "just
work". However in this case it sounds like a config fault somewhere -
possibly at thedj.

        Nigel.

-- 
[ Nigel.Metheringham@theplanet.net   -  Systems Software Engineer ]
[ Tel : +44 113 251 6012                   Fax : +44 113 234 6065 ]
[      Real life is but a pale imitation of a Dilbert strip       ]