Hey Dudes!

First off, I apologize for this post being so late. It should have been about a month ago. I’m moving on from RubyAMF. It’s been such a good time talking and meeting people who supported my efforts on RubyAMF. I couldn’t say thank you enough – but I could write a loop for you.

while(true)
{
 trace("THANK YOU");
}

Put this in Flash and try it. I know you’ll love me.

Anyway. I put a ton of effort toward RubyAMF, and they haven’t gone unnoticed, it’s so cool. And I’m glad I was part of helping out make strides for remoting in Ruby.

I’m definitely not done with AMF though. Trust me . I must say AMF is by far my favorite thing to work with when using Flex or Flash. It’s kind of awkward that I’m so passionate about AMF, but it’s an amazing creation from Macromedia with so many benefits.

As mentioned, I’m definitely not done with AMF, or writing / releasing cool stuff. First off. I’m sitting on PythonAMF. It’s not ready for a release yet. I need to do quite a bit of testing yet but it will happen.

I’ve also got another version of SSR done that I will release beginning of February. It includes great new additions. Here’s a quick breakdown of the new features.

Call limiting – Turning this on puts a remoting service in a state that will not allow duplicate calls to the same remoting service if a response has not been received from a previous one. Finally, this is built in so we don’t have to have scattered logic all over to handle this. This is extremely important because you can’t risk someone figuring out that you don’t limit calls made to the server, and then they smash your server. Ouch.

Caching – If a previous request is called again, it comes from cache instead. This includes options to expire cache after a certain time or after the cache has been hit a certain amount of times.

Paging – Yeah! Now there is a paging mechanism for those flashers (or flexers) who don’t get to use remote object. Or just don’t want to use remote object. Page buffering is built in, so you can set the buffer size to say 3 pages, and anytime there is only a certain amount of local pages (which you can specify) it retrieves the buffer pages. It has an iterator like interface so it’s all taken care of. As well as allowing “releaseAll,” some might remember that from Flash 8.

Paging is also built in a way that allows you to extend the default PageResponder (which you don’t have to touch by default). But this is nice if you want to put paging on a certain remoting service call, but the results you want to page are nested within the result object you get back.

I’ve also got a custom display renderer mechanism with the same iterator like interface that allows you to use a pager, (with say 50 items per page at a time), and have an interface for only displaying 10 at a time. So it’s like sub paging on the actual pager.

I think that’s it for new features. If I think of any others I added I’ll let you know.

Another issue I’m addressing is AMF stress testing. So far I’ve only seen the Flex Stress Testing framework which could possibly be used to test AMF gateways. But the amount of users it can act as to hit the server with is pretty limited, and the tool is so overwhelming to get setup.

AMF stress testing is exactly like it sounds. Test your AMF gateways with millions of hits. This is very important when working on something that is expected to have high volume traffic. I’ve experienced numerous sites that had high volume traffic and the server side couldn’t handle it. One in particular was remoting and just couldn’t take the hits. (Not because of AMF inefficiency, but because of server inefficiency.)

So as a way of spreading the word, that we can’t just blindly put up remoting gateways for a web site and not think anything of it. I’ve come up with a very simple way of stress testing AMF.

Here’s a quick rundown of how this all works.

There are a couple tools involved. First, a “capture client”, which is a simple Flex app that you fill out your service target, method name, arguments, amf version, and if it’s remote object or not. When that request is sent, it’s sent to a local “capture server.”

The “capture server” is a ruby webrick server that takes an incoming request and writes the raw post to a file (the AMF).

The next step in the process is JMeter. JMeter is an all around stress testing tool for many different web protocols. Jmeter was the only one I’ve found so far that allows for sending a POST request with “arbitrary binary data” (from RFC1867 secion 3.3).

That’s how the Flash player sends over AMF to the server, as stated in RFC1867, AMF is just arbitrary binary. Anyway, since the AMF is just in the body, all you really have to do is send an HTTP Post request to the gateway, along with the binary captured from the capture server. And voila, you can hit the gateway as many times as you want triggering your remoting software to react and perform the same operations as what would occur when a flash / flex request comes in. This is also very important, because it’s the software you write that get’s triggered for every remoting call. We can’t just hit an index.html page and assume everything is ok, when actually none of your server software is being tested.

The other piece to the puzzle is validating response. So far I’ve been using a tool called PlasticSniffer. It’s a very simple packet sniffer that will allow you to see the requests / responses of AMF. Generally you can see the UTF data in the response, which is just some text so you’d be able to read most of what’s going on. With some awkward characters tossed in.

So Anyway, I have been very busy working on more AMF goodies and will continue to be involved with AMF. Please stand by for SSR2 and that AMF capture tool, with JMeter instructions to get that running.

I had a great time with RubyAMF. And hope to hear from all of you in the future.

-Aaron