That part is not AMF specific - and Apache or Tomcat will have no issues of doing it - that is purely bandwidth issue.
As far as AMF/RTMP streaming main issue is robustness. It is very easy to get any of the products to run on the reliable network. We do use OpenAMF and proprietary performance extensions on low cost/ non-critical projects. For high-end applications we extend LCDS stack to fix underlying TCP/IP problems( financial clients, real-time messaging). We do not advertise low end product as it potentially might have reliability problems. Indeed, in order to provide even basic recoverability and batching on the top of openAmf we had to write tons of code. Only with significant investment and "know how" you can get comparable performance and reliability Unless Adobe releases both ends of the protocol in the open source you would have inherient reliability issues. While we acquired significan "know how" in the last 2 years, using native AMF and RTMP classes is a risky business as Adobe constantly changes framework and pieces of protocol. The main effort of the testing should be around protocol performance and reliability ( like pulling the network wire).and it can be a while till AMF/RTMP will become standard - most likely only after release of the client/server code in open source. Sincerely, Anatole Tartakovsky On 11/15/07, Steve Hueners <[EMAIL PROTECTED]> wrote: > > Is there anyway to judge what level of user connections a given server > can handle without requiring specialized loadsharing strategies? In a > non-audio or video environment what's it take to stream an AS3 based swfs to > 3-5 dozen connections? > > > > On 10/16/07, Anatole Tartakovsky <[EMAIL PROTECTED]> wrote: > > > > I would try to see if you can scale application in any other way - 4 > > core single CPU and removal all business functionality to different servers > > is always an option. You might get even better scalablity by going RTMP > > route or provide pseudo-connectivity wrapper using non-blocking IO via > > client - proxy - LCDS - Messaging - LCDS - proxy -client pish. > > > > Regards, > > Anatole > > > > On 10/16/07, Bruce Hopkins <[EMAIL PROTECTED] > wrote: > > > > > > Yeah, I'm using HTTPService right now with E4X results. The for > > > large data results, however, XML is not desirable. > > > > > > I'd prefer to use some framework that uses AMF3 in order to get more > > > compact results. > > > > > > Bruce > > > > > > > > > On 10/16/07, Jeff Schuenke <[EMAIL PROTECTED] > wrote: > > > > > > > > You can also just use HTTPService to do direct HTTP requests. I am > > > > > > > > using this for communications with a JAVA backend. > > > > > > > > --- In [email protected] <flexcoders%40yahoogroups.com>, > > > > "Bruce Hopkins" <[EMAIL PROTECTED]> > > > > > > > > wrote: > > > > > > > > > > Hi all, > > > > > > > > > > All I want to do is have my Flex client to communicate with my > > > > Java > > > > backend. > > > > > Due to licensing restrictions, LCDS won't be an option for us. So > > > > far the > > > > > biggest contenders are: > > > > > > > > > > 1. Granite Data Services > > > > > 2. OpenAMF > > > > > 3. WebORB > > > > > 4. Red5 > > > > > > > > > > Does anyone have any strong opinions, suggestions, or biases on > > > > either of > > > > > these solutions? > > > > > > > > > > Thanks, > > > > > > > > > > Bruce > > > > > > > > > > > > > > > > > > > >
