Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (513)
Games in Android Showcase (120)
games submitted by our members
Games in WIP (577)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Anyone ever tested RMI for a game ?  (Read 4373 times)
0 Members and 1 Guest are viewing this topic.
Offline ickylevel

Innocent Bystander





« Posted 2007-08-26 14:15:28 »

If made a mp game , it won't be about sending some key value but about creating/updating objects , wich is harder to implement Tongue.
So , there is that RMI. Is it good ? I had some bad experience with Pyro (remote object for Python).
If I made an RTS game aproximately like that :
- At least 2 players (the number will depend on network capability).
- A tickrate of 2 to 5 (not very important because nothing will be updated every tick , the question is "do RMI send any info if the result of the method of an object is nothing" (yeah look like a stupid question)).
- The world is a 100X100 grid , for each coordinate there is an object to store the information about the area.
- Most of the area are "empty" so if RMI send the info only when they change , we can assert only 200 "static" objects needs to be updated (sry if I can't say exactly what is going to be updated per object ,  I assume not more than 100 bytes).
When possible objects are updated with a period wich range from 5 seconds to several minutes (what we could call static objects such as buildings).
What we can call "units" (100 of them would be enought) will probably need to be updated only each seconds (it will take for the fastest unit 1 seconds to get from a zone to an another one). Everything is an attribute of the zone class wich define an area , so you know where an object is in the world by looking in wich are object it is . Is it a good solution or is making the position of the unit two value for x and y better (in term of networking)?
And then , there are the actions the player trigger , wich can happen at any time , but it's probably negligible compared to the periodic update thing.

So , it's very hard to tell how bandwich consuming it will be since I'm not sure of how RMI works...

Any example of network game made with RMI (as "big" as possible) ?
Offline Conzar

Junior Duke




There is nothing common about common sense


« Reply #1 - Posted 2007-09-21 20:20:36 »

Another Link on performance of RMI (I was actually surprised by this)
http://martin.nobilitas.com/java/thruput.html

We are actually using RMI in a current game that we (Monky Games)  ... plan on having a beta in December so will post back in Jan or Feb with feedback.  Can't say what the game is right now b/c of company policy.

Ubuntu
Offline sunsett

Senior Duke




ribbit!


« Reply #2 - Posted 2007-09-23 18:18:47 »

I can understand the desire to use something like RMI but the performance would be very problematic in any but the most basic games.

When I encountered a need for similar functionality I wrote it into JGN (JavaGameNetworking: http://javagamenetworking.dev.java.net) to do the following:

RemoteObjects - Provides the ability to instantiate a Class that implements an interface (like in RMI) and then give it a unique name.  Then remote connections can simply make a call to get an instance of that name and they will get a Proxy object that will invoke the methods over the network for you.

SharedObjects - Given a Bean you can instantiate it on one machine and get real instances of it on the remote machines and when one machine calls a setter the information is synchronized to all other machines in real-time.  This gives you a single Object that is shared across multiple machines.

Both use customized serialization so it's much faster and more efficient than standard Java serialization.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline sunsett

Senior Duke




ribbit!


« Reply #3 - Posted 2007-09-23 18:21:49 »

For further details see the examples in SVN here:

http://captiveimagination.com/svn/public/jgn/trunk/src/com/captiveimagination/jgn/test/so/basic/BasicSharedObjectClient.java
http://captiveimagination.com/svn/public/jgn/trunk/src/com/captiveimagination/jgn/test/so/basic/BasicSharedObjectServer.java
http://captiveimagination.com/svn/public/jgn/trunk/src/com/captiveimagination/jgn/test/so/basic/MySharedBean.java
Offline Conzar

Junior Duke




There is nothing common about common sense


« Reply #4 - Posted 2007-09-24 15:33:32 »

Do you have any benchmarks to back up that RMI is slow and JGN is fast?

Ubuntu
Offline sunsett

Senior Duke




ribbit!


« Reply #5 - Posted 2007-09-24 17:18:37 »

There are benchmarks in the tests for JGN that show its level of performance, but I never really figured anyone would ever question the performance (or lack thereof) using RMI.  There are many people here that are Java networking gurus, and if even one believes RMI can be performant in game development I would put together a benchmark.  Smiley
Offline Conzar

Junior Duke




There is nothing common about common sense


« Reply #6 - Posted 2007-09-24 18:03:51 »

There are benchmarks in the tests for JGN that show its level of performance, but I never really figured anyone would ever question the performance (or lack thereof) using RMI.  There are many people here that are Java networking gurus, and if even one believes RMI can be performant in game development I would put together a benchmark.  Smiley

So are you saying that you are gonna put together a benchmark for RMI?
BTW, I've posted this in another forum.

http://martin.nobilitas.com/java/thruput.html

Ubuntu
Offline noblemaster

JGO Ninja


Medals: 20
Projects: 10


Age of Conquest makes your day!


« Reply #7 - Posted 2007-09-24 19:07:43 »

Quote

Those are some interesting results! I would never have figured. Who knows, "RMI is slow" is probably an urban legend similar to people saying Java is slow?

Offline sunsett

Senior Duke




ribbit!


« Reply #8 - Posted 2007-09-24 22:35:29 »

It's not an urban legend, you're just comparing different things. Shocked

There's a big difference between comparing something for use in an application versus use in a game.  23ms to send 10bytes is slow in my opinion.  Bandwidth aside JGN can send well over 1 million "Messages" per second and they would most likely be larger than 10 bytes...I'd have to look again at my benchmark test.  But if you want to add that to results you're talking about 0.001ms per 10 bytes.  This is why I don't think it's worth doing an official benchmark.  Tongue

Most of my testing uses nanoseconds instead of milliseconds both for better accuracy and precision.
Offline noblemaster

JGO Ninja


Medals: 20
Projects: 10


Age of Conquest makes your day!


« Reply #9 - Posted 2007-09-24 23:48:58 »

I am not saying it is. I am just trying to get someone to disprove or confirm the claim. Would be interesting to see if this is actually true Grin 
 
Quote
Bandwidth aside JGN can send well over 1 million "Messages" per second and they would most likely be larger than 10 bytes
So far all you do is arguing a point without any proof? 1 million messages a 10 bytes comes down to about 80MBit/sec - not sure what kind of game is going to use that in the near future, let alone the players with that kind of connection at home  Smiley

Let me make my claim: RMI can send 2 million "Messages" per second and they would most likely be larger than 20 bytes. It's the JGO Forums, so I can make any claim I want without the need for backup...


Edit: minor

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline sunsett

Senior Duke




ribbit!


« Reply #10 - Posted 2007-09-25 01:21:23 »

I'm not making a claim without backing it up.  My claim is that JGN can send 10 bytes in 0.001ms.  If you need proof, just run the TestStressMessageServer Class in JGN.  I really have no interest in the debate, I was just trying to help.  If you're more interested in arguing I withdraw my assistance.

Good day.  Tongue
Offline Conzar

Junior Duke




There is nothing common about common sense


« Reply #11 - Posted 2007-09-25 18:07:52 »

Quote
There's a big difference between comparing something for use in an application versus use in a game.

Isn't a game technically an application?  Or am I missing something here?

Again,  if you would like to help us, then please don't make claims like ... RMI is slow ... these types of descriptions really don't help us.  If however, u can say look at these benchmarks for RMI compared to JGN ... JGN is X times faster for these benchmarks.  Even better, having benchmarks that rates RMI, Sockets, JGN, and other Network packages would be great.

I would also argue the need for not only theoretical benchmarks but also real world.

Here are the conditions that would convince me of the "fastest" using a set of test cases in the following environments
* loopback mode (server and client run on 1 machine)
* LAN (server is on one machine while client is on another connected via a high-speed switch ... preferably 1Gb)
* WAN (server that is on 1 machine and client is connected via the internet ... means there are most likely hundreds of routers and switches between the two ... this test is very difficult and must be run continously over a long period of time ... also would need to run the client at several locations away from the server).

Ubuntu
Offline sunsett

Senior Duke




ribbit!


« Reply #12 - Posted 2007-09-25 18:33:39 »

I was referring to non-game application development (standard use of RMI) versus game development, I just assumed that was obvious.  Sorry for the confusion.

Though I can appreciate your desire to have benchmarks that lay out properly defined tests and stack data up unfortunately I don't have the time (and you would likely be hard-pressed to find many that either have the time or are willing to) to create such tests right now.  JGN is an open-source project and though I try to make a good effort to maintain it and ideally I want to have pretty graphs showing how much faster it is than everything else I just simply don't.

I was trying to do the next best thing by giving you an approximate performance equivalent of JGN versus the benchmark on RMI you mentioned.  Based on the performance benchmark you mentioned JGN is significantly faster, but that's something you'll have to evaluate for yourself if you want certified tests to prove it.

JGN supports running multiple servers and clients on a single machine.

If you are interested in setting up some official benchmarks I'd be happy to provide any support I can from JGN's side of things.
Offline Conzar

Junior Duke




There is nothing common about common sense


« Reply #13 - Posted 2007-09-25 21:02:16 »

Quote
My claim is that JGN can send 10 bytes in 0.001ms

So looking at the benchmarks on the site that I referenced: the investigator is comparing the different methods of serializing an object and sending it and receiving it across the wire (network).  What this experiment shows is an object is created on the client, sent to the server, the server unpacks it and repacks it, and then the object is sent back to the client.

For the claim quoted above: is that claim for serializing an object or is it just simply sending a buffer of 10bytes across the wire, is it for an object that is created on a client, sent to the server, and then sent back to the client?  There is a big difference between sending a buffer of 10 bytes then serializing an object and sending it as well as just sending an object 1-way.

Also note, the first set of benchmarks was recorded via a 802.11b LAN (10Mb/s theoretical bandwidth).

The last set of benchmarks was via loopback ... the results for RMI for 10bytes is 4.8ms round trip time (when the object was created on the client to the server and back again).

Thanks for your help ... note, no-one here is trying to attack anyone, make anyone look bad, or any other malicious activity.  We are simply trying to get at the facts and the truth that will help us in our game development.

Ubuntu
Offline noblemaster

JGO Ninja


Medals: 20
Projects: 10


Age of Conquest makes your day!


« Reply #14 - Posted 2007-09-25 21:19:44 »

Quote
note, no-one here is trying to attack anyone, make anyone look bad, or any other malicious activity.
Speak for yourself my friend! I am here for the bashing  Grin

Nee, seriously, JGN is on top of my list for real-time networking. I am not sure if I am going in that direction (real-time gaming), but if I am, I am definitely interested to check out JGN  Smiley

Offline sunsett

Senior Duke




ribbit!


« Reply #15 - Posted 2007-09-25 21:53:01 »

For the claim quoted above: is that claim for serializing an object or is it just simply sending a buffer of 10bytes across the wire, is it for an object that is created on a client, sent to the server, and then sent back to the client?  There is a big difference between sending a buffer of 10 bytes then serializing an object and sending it as well as just sending an object 1-way.

It is serialized objects...in fact, that's what JGN is all about.  In JGN you create custom Message objects that are essentially beans with extra functionality and you send them them to other clients.  Then on each client you can add MessageListeners to handle receipt of different types of messages.  That is the core foundation of JGN and what everything else builds upon....and yes, it's about that simple to use as well. Wink
Offline Conzar

Junior Duke




There is nothing common about common sense


« Reply #16 - Posted 2007-09-27 15:35:52 »

Alrighty mr JGN ... do you have any documentation on the JGN architecture?  Also do u have any user docs?  I looked through the test u posted earlier ... but it would be nice to have some explanations Wink

Does JGN have a registry like RMI?

I also wrote my own benchmark util and came up with some benchmarks for RMI
* Experiment *
% Server started (which is a remote object) and is registred
% Client is started (following steps are for the client
  % Created an object that contains a buffer of size 10 bytes.
  % Get Server Object from RMI registry
  % capture time in nanoseconds (System.getNanoTime())
  % call remote method and pass the object that contains 10 byte buffer
% Server returns remote object
% client records end time in nano seconds
% this time is saved in an array (endtime - starttime)
% repeat for 10k times
% average round-trip time

For the above procedure I ran this test in loop-back mode and got an average time of 0.0621ms.
Not too shabby (using sun jre 1.5)

I also ran another test that was exactly the same as the one above except that the server did NOT return an object (meaning its a one-way communication) and I was able to get 0.0477ms time.

These benchmarks show a much improved RMI system from when the benchmarks that I posted before were performed (up from 4.8ms to 0.0621ms).

Still slower then the claimed JGN benchmark of 0.001ms though but RMI might still be viable ... depends on the game I guess.

Ubuntu
Offline sunsett

Senior Duke




ribbit!


« Reply #17 - Posted 2007-09-27 17:35:30 »

There was a lot more explanation on our wiki, but it sort of broke and I never got around to updating it since I keep holding out in anticipation that I'll find the time to create an actual site for the project. Wink

The "tests" package in JGN really is the best way to get started with JGN.  I'd love to have a Getting Started guide and all the rest, but I'm just one person and though I get frequent contributions from the community on JGN I haven't found anyone yet that's willing to either create a Joomla site (or any other for that matter) and/or create some better documentation than the tests + JavaDocs.

That is definitely much improved from the benchmark stats in the referenced article.  That wouldn't be too shabby for games that either don't send a lot of messages or care less about real-time data...even for some real-time data it might be usable.  RMI has definitely gotten a lot easier since the early days, but I would still suggest that JGN is easier once you understand how to use it.  Another benefit to JGN above RMI is you can do asynchronous requests instead of synchronous (invoking a method obviously must block until it gets the response) if you so desire which keeps a thread in your game from getting stuck waiting for some information.
Offline Conzar

Junior Duke




There is nothing common about common sense


« Reply #18 - Posted 2007-10-01 17:23:00 »

Alrighty, I have another question ... this is after looking at some of the programs in jgn...test

So can you call a method on a "remote" object? 

Example in RMI
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
public interface RemoteServer extends java.rmi.Remote{
   public void remoteMethod() throws RemoteException;
}

public class Server extends UnicastRemoteObject implements RemoteServer{
     public Server(){
          // create registry and register with it
     }
     public void remoteMethod() throws RemoteException{
        System.out.println("remote method called");
    }
}

public class Client{
    public Client(){
        Server server = (Serverjava.rmi.Naming.lookup("rmi://localhost:1000/server");
        server.remoteMethod();
    }
}


This is pretty easy.  We don't need to define a "Message" object in RMI.  We only need to define a RemoteObject ... which tells rmi that this object can be accessed by "clients" via calling the functions defined in the interface.  How do u do this in JGN or is this not possible? 

I think creating messages, serializing them, and sending/receiving them is a different model ... in fact, I've created my own framework to do this in a previous project.  The problem with this method is that it gets messy the more messages that you have (100+ messages and you have some switch statement that checks the type and then calls a function based on that message).  Its much cleaner to just call the function from the client.

Anyways, can u do this in JGN and if so, how?

Ubuntu
Offline sunsett

Senior Duke




ribbit!


« Reply #19 - Posted 2007-10-01 18:47:21 »

Code examples I can handle. Smiley

The interface:
1  
2  
3  
public interface MyObject extends RemoteObject {
    public void remoteMethod() throws IOException;
}


The implementation:
1  
2  
3  
4  
5  
public class MyObjectImpl implements MyObject {
    public void remoteMethod() throws IOException {
        System.out.println("remote method called");
    }
}


Local implementation side:
1  
2  
3  
    ... Set up the MessageServer ...
    MyObjectImpl myObject = new MyObjectImpl();
    RemoteObjectManager.registerRemoteObject(MyObject.class, myObject, messageServer);


Remote implementation side:
1  
2  
3  
4  
    ... Set up the MessageServer ...
    ... Establish MessageClient connection to remote machine ...
    MyObject myObject = RemoteObjectManager.createRemoteObject(MyObject.class, messageClient, 5000);
    myObject.remoteMethod();


That's pretty easy, right? Smiley  The 5000 on the remote implementation is the only thing that may not be self explanatory.  That is the timeout period if the object is not connected within the specified time.
Offline sunsett

Senior Duke




ribbit!


« Reply #20 - Posted 2007-10-01 18:57:09 »

Also, if you would rather just do bean data synchronization (particularly useful for game data in a game where multiple clients can modify, or at least read specific data about an object) check out the SharedObject system in JGN.  It allows you to define an interface like:

1  
2  
3  
4  
5  
6  
7  
8  
9  
public interface MySharedBean {
   public String getOne();
   
   public void setOne(String one);
   
   public int getTwo();
   
   public void setTwo(int two);
}


Then you can create instances on multiple machines of that bean that synchronize for you.  Take a look at the samples:

http://svn.javagn.org/core/trunk/src/com/captiveimagination/jgn/test/so/basic/BasicSharedObjectServer.java

http://svn.javagn.org/core/trunk/src/com/captiveimagination/jgn/test/so/basic/BasicSharedObjectClient.java

You can even add listeners to the SharedObject to be notified when any of the data changes. You'll know what "field" was changed, what it was changed to, and the MessageClient that is responsible for the change.  This is extremely powerful if you're wanting stateful data synchronized over many clients or even just client to server.

These are just two of the many features JGN provides.  I think it's also relevant to point out that these are "extensions" to the core functionality of JGN.  The beauty of this is that this kind of functionality can be written by anyone.  It shows the power of the core of JGN to support nearly any usage.
Offline Conzar

Junior Duke




There is nothing common about common sense


« Reply #21 - Posted 2007-10-02 12:47:50 »

What are the messageServer and messageClient in the above example?

Are they the JGNServer and JGNClient?  Or are they actually the MessageServer and MessageClient.

Because I am pretty confused on how the MessageServer and MessageClient are setup.  The JGNServer/JGNClient seem more intuitive...

Ubuntu
Offline sunsett

Senior Duke




ribbit!


« Reply #22 - Posted 2007-10-02 13:14:39 »

They refer to MessageServer and MessageClient.  I've considered changing the name of those classes so they make a little more sense.  Though they are correct terminology, typical usage of "server" makes it confusing.  The MessageServer is the core of JGN, there are two types of MessagesServers: TCPMessageServer and UDPMessageServer.  You instantiate a MessageServer and that is responsible for connecting outward to establish new MessageClients and/or listening for inbound connections and creates MessageClients.  The MessageServer is a "server" and MessageClients are the individual remote connections that have been established from a MessageServer.

JGNServer and JGNClient are part of the Client / Server convenience classes that provide common functionality for your typical client / server game.  They actually encapsulate two message servers (a fast server and a reliable server - typically UDPMessageServer and TCPMessageServer).  However, you can define only one or the other if you only want to communicate via TCP or UDP.  Both JGNServer and JGNClient have logic internally defined to decide how messages should be sent.  For example, a CertifiedMessage (a message with guaranteed deliverability) will always prefer to send via TCP whereas a RealtimeMessage (typically used for things like synchronization) prefers to go through UDP since it's not critical that every message reach the destination.  There are several interfaces that custom Messages simply need to implement in order to gain functionality like this.
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Longarmx (52 views)
2014-10-17 03:59:02

Norakomi (43 views)
2014-10-16 15:22:06

Norakomi (33 views)
2014-10-16 15:20:20

lcass (37 views)
2014-10-15 16:18:58

TehJavaDev (68 views)
2014-10-14 00:39:48

TehJavaDev (67 views)
2014-10-14 00:35:47

TehJavaDev (60 views)
2014-10-14 00:32:37

BurntPizza (73 views)
2014-10-11 23:24:42

BurntPizza (45 views)
2014-10-11 23:10:45

BurntPizza (86 views)
2014-10-11 22:30:10
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!