[MUD-Dev] UDP Revisted

Bobby Martin bobbymartin at hotmail.com
Tue Oct 23 20:49:25 CEST 2001


> From: Bruce Mitchener <bruce at puremagic.com> 
> Bobby Martin wrote:
>> From: "Adam Martin" <ya_hoo_com at yahoo.com> 
 
>> Use ARMI (http://sourceforge.net/projects/armi/)
 
> I was curious as to what sorts of advanced features you had in
> ARMI and the documentation didn't really go into much detail
> beyond some usage notes.
 
> Do you have any support for pipelining of requests?

No, although TCP (which I currently use) buffers packets for up to
200 ms before it sends the buffer.

> How about for monitoring message traffic or requests for
> debugging, checking load balancing, etc?
 
Currently in the works, but not there right now.

> What sorts of security or authentication do you support?

Currently, none :( It is fairly trivial to add an encrypting message
filter, though.  You can filter messages that you send any way you
like.

> Can you compare your packing overhead to that of RMI or other
> systems? Do you compress your datastreams?

We don't currently formally compress data streams.  I have done some
sampling of RMI throughpuut versus ARMI throughput; ARMI was about
10 times smaller for the method calls I tested.  This definitely
needs more formal testing.

The main things that ARMI does is allow you to insert filters to
compress, encrypt, etc. messages however you like and it uses class
and method ids (four bytes each) instead of fully qualified strings
(I'm not sure how big the RMI method descriptors are, but they're
big.)  The other thing that improves performance is that you tell
ARMI how to serialize your objects.  You can define your own
serialization for RMI, but you still have the wrappered information
describing the class which is quite large for RMI.

> Any more information to explain in more detail how/why ARMI is
> great is welcome. :)

So I guess the answers I have really aren't very satisfying right
now.  We do have someone working on a performance test harness, and
when he gets that complete I will ask him to run some comparisons
between RMI and ARMI to give formal results.

Offhand I don't know what I can tell you about why ARMI is great
that isn't listed on the web site.  Main attributes are:

  1) Your method calls can be asynchronous (your app doesn't stop
  and wait for the return value from a method call until you need
  the return value.)

  2) I use ids for the class and method instead of the huge
  descriptors that RMI uses.

  3) You can swap out the underlying transport mechanism or put
  filters in to change the behavior to implement things like
  encryption, authentication, compression.

  4) <not implemented yet> You can choose whether a method call is
  guaranteed or not.  Currently you either use UDP for transport and
  all method calls are non-guaranteed but fast, or you use TCP for
  tranport and all method calls are guaranteed but slower (but still
  much faster than RMI).

I have implemented production compression systems before, and I can
tell you that you will almost certainly need tailor made compression
(i.e. just write clever serialization code) for any significant
gains.  Lots of small information packets are hard to compress,
unless you take large production runs and analyze them, then
compress assuming the usage patterns don't change too much.  Most
compression mechanisms require that every block of data you compress
has a table describing how to decompress it, and for small blocks
the table takes up more space than the amount you gain by
compressing.  If you analyze large production runs of data, the
tables can be static and just sit on either end of the connection.

Bobby
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev



More information about the mud-dev-archive mailing list