On 30 Dec 97 at 13:06, Nigel Metheringham wrote:
> masq code. It is not sufficient to write a cache function - that would
> require a better knowledge of the control protocol and also something
> about the data protocol (which you need not know about for the proxy
> functions). PN do not give that data away - I wish luck to anyone
> attempting to reverse engineer that protocol info :-)
As far as I know, Real Player data stream is UDP stream with no
guarantee of packets to be delivered at all. From Real Player
functionality, one can see that there is some negotiation between
client and server, but only about quality of line and general
throughput, it is not packet recovery (I know it can use TCP, but it
is than less effective, preferred is UDP). Data stream recovery for
purpose of real media broadcasts is totally different task.
For such a case, I can not imagine caching of such connectionless
data stream (1st cache gets some packets lost, 2nd cache in chain
gets even more packets lost, ...)
For playing of archive files, there is probably not good solution
(unless way of operation of streaming is totally changed - or TCP is
used - which is already implemented), for playing live streams there
could be installed something like reflectors, which I think are
already supported by RealMedia.
Of course it could be possible to mix TCP/UDP connections (i.e., UDP
between last cache in chain and client, TCP on all other
connections), but I suppose it is totally new application built from
scratch with full reflector functionality, squid is probably not good
platform for it.
Regards
Jan Klabacka
Received on Tue Dec 30 1997 - 02:34:41 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:38:06 MST