Or from the current tag:
script/plugin install http://rubyamf.googlecode.com/svn/tags/current/rubyamf

Now, for anyone interested, what was breaking was Rails 2.1’s forgery
protection, which stops cross site scripting attacks by placing a
security code in HTML and Ajax forms and verifying that that’s the
right code on the Rails side.
My fix was just to add the AMF mime type to the list of mime types
that aren’t checked for forgery protection, alongside XML and JSON. I
think it belongs there, because there’s no way that I know of to hook
into the Rails forgery protection.
To do the same type of thing from a Flash app would be a bit of a
different process, and I’m not quite sure what the best way to think
about that is, nor if it’s actually a problem we need to worry about
anytime soon. Any thoughts?
Upshot: RubyAMF 1.6 for Rails 2, RubyAMF 1.6.1 for Rails 2.1.

Cross posted from (http://groups.google.com/group/rubyamf)

So, I guess here’s the obvious. SSR is a small AS3 remoting library. Stands for “Super Simple Remoting” because it’s simple. My goal when writing it was to make one library that works in Flash and Flex and handle logic that should be in every application. Personally I like using this in both Flash and Flex because I don’t forget how to use it. I always forget how to use RemoteObject so this makes a standard library for either.

So here’s an example of a bare minimum setup of SSR to make a remoting call.

import com.niarbtfel.remoting.RemotingConnection;
import com.niarbtfel.remoting.RemotingService;
import com.niarbtfel.remoting.events.FaultEvent;
import com.niarbtfel.remoting.events.ResultEvent;

var rc:RemotingConnection = new RemotingConnection("http://localhost/myGateway",3);
//gateway
//3 is the amf format

var rs:RemotingService = new RemotingService(rc,"MyService",4000,3,true);
//rc is the remoting connection to use for this service
//"MyService" is the service target on the server.
//4000 is the amount of time a call waits before retrying the call.
//3 is the amount of retries to attempt per call.
//true turns on call limiting, which means that the same exact call can't be made while one is waiting for a response or timeout.

//callbacks for calls, keep reading.
function onr(re:ResultEvent):void{}
function onf(fe:FaultEvent):void{}

//callbacks for calls, keep reading.
function onrArgs(re:ResultEvent,args:Array):void{}
function onfArgs(fe:FaultEvent,args:Array):void{}

rs.myMethod([],onr,onf,false); //make a call
//[] = call arguments
//onr is the result callback
//onf is the fault callback
//false - don't return the original arguments sent in the request to the callback functions

var mym:String = "myMethod";
rs.apply(mym,[],onrArgs,onfArgs,true); //make a call
//[] = call arguments
//onr is the result callback
//onf is fault callback
//true - return the original arguments sent in the request to the callback functions

This is the simplest form of setting up flash remoting with SSR without any event listeners on the RemotingConnection or RemotingService. Events for RemotingConnection and RemotingService are documented in the class files. You get events for things like disconnects, retries, timeouts, etc.

Each RemotingService can have a timeout specified for each call going to that service, as well as a maximum attempts allowed per call. If one call is made, but doesn’t receive a response within the timeout specified, it’s tried again. This happens over and over until the maximum attempts is reached, and a timeout event is dispatched.

RemotingService has an option to turn on call limiting. Which makes the remoting service smart about what to call and what not to call. If you made a call to “MyService.myMethod” with parameters ["something","something else"], it would not let you make that same call until the first one has completed, or has timed out. You’d still be able to make calls to any other service method.

Another new feature is caching. Say you make calls to some service numerous times, but the data is always the same. Instead of doing that you can enable the service to use caching. Here’s a snippet from above with caching in place:

var rs:RemotingService = new RemotingService(rc,"MyService",4000,1,true);
rs.remotingCache = new RemotingCache(-1);
//-1 specifies that the cache should never expire. (supply a time in milliseconds for an expiration if needed)

Now every call made through this remoting service will be cached. If the exact same call is made, the results are pulled from cache instead.

SSR also has paging built in with a RemotingPager. Here’s a snippet on how that works:

import com.niarbtfel.remoting.RemotingConnection;
import com.niarbtfel.remoting.RemotingService;
import com.niarbtfel.remoting.events.FaultEvent;
import com.niarbtfel.remoting.events.ResultEvent;
import com.niarbtfel.remoting.paging.RemotingPager;
import com.niarbtfel.remoting.paging.PageResponder;

var rc:RemotingConnection = new RemotingConnection("http://localhost/myGateway",3);
var rs:RemotingService = new RemotingService(rc,"MyService",4000,3,true);
var rp:RemotingPager;
var pr:PageResponder // just to include in compilation

var totalRecordsOnServer:int = 400; //should come from server instead.

//callbacks for calls, keep reading.
function onrArgs(re:ResultEvent,args:Array):void
{
  rp = new RemotingPager(rs,"myMethod",PageResponder,["someParameter"],re.result as Array,totalRecordsOnServer,50,2,1);
  myButton.addEventListener(MouseEvent.CLICK, onbc);
}
function onfArgs(fe:FaultEvent,args:Array):void{}

function onbc(me:MouseEvent):void
{
   if(rp.hasNext())
   {
     trace(rp.next());
   }
   else
   {
     trace("no more pages");
   }
}

rs.myMethod(["someParameter",0,50],onrArgs,onfArgs,true); //make a call to get the initial data.
//0 is the offset
//50 is the pagesize

In this example, a remoting pager is created in the result callback of the first call. A remoting pager needs at least the first page in order to be created. The RemotingPager takes care of “pre-fetching” pages with buffer options. In the above example, where the RemotingPager is created, 50 is the pagesize to grab, 2 is the amount of pages to buffer / pre-fetch. And 1 is the amount of pages that are left in the buffer before triggering another buffer fill / pre-fetch. This is the simplest form of paging, but the RemotingPager has methods for getting certain pages, getting them all, seeking, etc.

UPDATE: I forgot to mention RemotingService.MaxTimeoutsBeforeHault.

With RemotingService.MaxTimeoutsBeforeHault, you can control how many timeouts are allowed from any call, before all remoting calls are stopped. Here’s a snippet:

RemotingService.MaxTimeoutsBeforeHault = 3;
var rs:RemotingService = new RemotingService(rc,"MyService",4000,3,true);
rs.addEventListener(CallEvent.SERVICES_HALTED, onch);
function onch(ce:CallEvent):void{}
rs.myMethod([],onR,onF,true);

When you set this property, any call that causes a timeout, is kept track of, and if 3 timeouts happen from any call, no other remoting calls will be made. Each attempt after the services are halted, dispatches the CallEvent.SERVICES_HALTED event.

In conclusion – SSR gives you logic out of the box that should be available anytime we are using Flash Remoting. And gives you numerous other features. SSR 2 is documented very well in the source files.

UPDATE: Check out the SSR 2 Breakdown.

Anyway, I’m going to keep this short – here is a rough set of tools that will get you stress testing your AMF gateways. Make sure to read the “readme” in the zip file, this has enough instruction on the different tools, and the source for it all, so you can read through it, alter it, use it to your advantage.

Also, the capture client only works with SSR right now, but I’ve included the source for everything so you could go in and update the part that I left out which was support for Remote Object. It shouldn’t be a ton of work, sorry I couldn’t get that done.

I’ll be watching the RubyAMF mailing list for any help requests / questions about this. Hopefully this is really straight forward, and the readme does a pretty good job of explaining what’s going on with everything.

Enjoy.

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

In case any other AMF projects are interested in how we did this – I’ve extended the byte array documention here. I also put up a code example.

We’ve also changed how you receive them in your controller action. Previously you’d get string of bytes. But now we’re giving you an actual array of bytes. A byte array .

I don’t have any intention of writing byte array support into the serializer (send byte arrays back to flash from rubyamf). Anyone have any good use for this?