Hm, but why would you want a 302 at the perimeter? That sounds suspiciously like trying to solve a problem (loadbalancing?) at the wrong layer to me.
However, anything else?
I'm honestly curious, as until now I've been fairly ambivalent about RTMP and am a bit surprised about the flak it's getting. Especially with Apple's "oops we didn't know HTTP supports range requests"-hack being pitched as the alternative...
(edit: ah I see DarkShikari already set that one straight)
In a CDN environment, load balancing is a far more complex subject than can be entertained in this thread. Suffice to say that load balancing is not just about spreading requests evenly over machines, you have to make intelligent decisions. If the customer of the CDN is unwilling to lift a finger to do things differently when integrating with a CDN, you can have a problem. In the HTTP world, 302 redirects can work around that very efficiently, in certain cases.
As to what other problems RTMP has: 1) a significant amount of state and therefore RAM needs to be kept per connection 2) there is no standard URL format that describes where to separate the connect() string from the play() string 3) no standard way to specify query terms on the connect() string 4) it cannot be cached by nodes outside of the CDN 5) you are required to use Adobe's FMS if you need to use SWF verification or RTMPE which has significant other ramifications.
That's just what I can think of off the top of my head.
Yes I know, I'm running my own little Wowza cluster of a couple dozen hosts, so I have faced the same problems. ;-)
If the customer of the CDN is unwilling to lift a finger
Okay, I guess that's an argument - although I'm not sure to what degree this can be held against the protocol.
As for the other problems you mention (apart from the RAM issue), I can see how they can be problematic in a multi-tenant/CDN environment. I'm just not sure I'd want to see a transport-protocol packed with all those concerns, as that would result in a lot of bloat and half-baked trade-offs (i.e. quite possibly even worse than RTMP).
While some basic building blocks (e.g. the 302) would indeed be helpful, we have so far had good luck with encoding meta-data into the URLs (crypt/hmac) and handling the logic on the origin.
Anyways, thanks for the insight. It's always interesting to learn how other people use and look at these things.
However, anything else?
I'm honestly curious, as until now I've been fairly ambivalent about RTMP and am a bit surprised about the flak it's getting. Especially with Apple's "oops we didn't know HTTP supports range requests"-hack being pitched as the alternative...
(edit: ah I see DarkShikari already set that one straight)