Sorry; it was my assertion in this tread -:). Through it change nothing... Why don't start fron the replication/reflection, then go to the short-time-caching, may be to the long-time-caching, and then only to the multicasting. Those who is playing around multicasting now looks amazing - they build a complex, twisted routing schema with the PIM, etc etc to deliver usially ONE data stream to the ONE customer -:). May be, to the two customers. And then ask _why don't another want to play with them_. This was the issue - on the first stage, simple packet replication is just the same as multicasting, but is much simpler to inplement globally. And this is in fact caching with the zero time-to-expire. Alex.
If you think about it briefly, Vadim's assertion that "packet caching" and "multicast distribution" are indistinguishable if the packets are retained in the cache for essentially 0 time.
I think Vadim's point is that accepting the validity of the multicasting = caching assertion allows one to consider doing a better job of reducing the consumption of network resources by replayable content than the use of native multicast does.
(This is perhaps why Peter Lothberg and company have been working fairly hard at enabling the inflation of the use of Internet multicast, since the deployment costs of native IP multicast are so small that the ultimate non-scalability of IP multicasting (or multicasting in general if you accept Vadim's argument) does not prevent people from turning on PIM/SM+mBGP+MSDP. First you roll (excuse the pun) out Compare the multicsting listeners and RealVideo or RealAudio or MP3
Just right. listeners; first are 1% of the last. What multicast deploying are you talking about, it's a myth yet. Aleksei Roudnev, Network Operations Center, Relcom, Moscow (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 230-41-41, N 13729 (pager) (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)