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.

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.

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.)

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.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org