The magicosm project has a spin-off open source project called ARMI. Fast, compact, asynchronous Java messaging system. Alternative to Java RMI. Pronounced “army”.
We use it for the client-server communications and could be useful to some people.
Feel free to take a look. It is a mature and stable product. I know our ARMI engineers recently solved some performance problems using NIO, so perhaps it is particularly relevant to the current dicussions in this group.
Excellent! I will go and take a look!
I remember when you had mentioned the asynch RMI you guys were working on last year, and I never got around to checking it out, so thx for the link. 
–Brad
Wurm Online will probably upgrade to ARMI as soon as the log4j requirement goes away. 
Anyone having any problems trying to access the CVS repository on SourceForge for this project?
I’m not even able to login to the repo without an error; [login aborted] Could not find home directory.
I’ve had this problem with various sf.net projects,
try different connection strings
e.g.
@cvs.sf.net:/
@cvs.sourceforge.net
@cvs.project.sourceforge.net
etc
That usually make the download work (have no idea as to why though… 
I still haven’t d/l’ed the source, but I looked through it on the online CVS at SF.
I have two questions, both related.
Why would I want to use RMI, or ARMI in this case, as opposed to a simpler scheme of just passing numeric messages to my server?
Similarly, why would I NOT want to?
I’ve only used RMI twice. Once was a test project so I could say “Cool, I think I understand the basics of RMI, but not the intricacies.” And the other was on a client/server based project. Eventually the RMI section was abandoned in favor (get this) of a full-blown message queueing system.
Therefore, please excuse my ignorance.
Very good questions. I’ve always considered RMI more of a gimmick than anything else… it seems way too inefficient and actually just plain silly to pretend to do normal method calls over a somewhat unreliable slow network connection. Yet it does certainly save you from coming up with something yourself.
Of course I think SOAP, CORBA, and DCOM are dumb too but apparently people really use that stuff.
I’m glad I can stick to ‘fun’ client side stuff. Hmm actually I did write a server for stuff at work… I used a plain ASCII command interface, so without the client app you could still do everything with telnet. (Great for debugging too.)
Hoo boy, I’d much rather use RMI than a raw protocol, as RMI lets you specify the entire client-server protocol as just a small set of interfaces, instead of page after page of cryptic .txt files.
That said, we recently decided to go with a raw udp protocol for wurm. One good look at Project: Entropia made us realize that fast networking is essential in an MMORPG. =/
[quote]I used a plain ASCII command interface, so without the client app you could still do everything with telnet. (Great for debugging too.)
[/quote]
As long as the return value or the arguments for your command isn’t a complex object thats fine …
True, but I have really never found a need for returning complex objects… well I guess that is not true… I return complex documents as XML - which is actually comes out smaller and is more portable than normal serialized objects. But for gaming there would be a significant speed trade-off parsing XML for state changes in a highly interactive game.
This is where Cas’ structs proposal starts to look good. If I follow his idea correctly complex structs could be mapped from the same byte buffer that is used for network IO.
I think that the general solution of RMI is not efficient for games. Maybe web transactions that happen at a much more relaxed rate.