New RPC library - Asynchronous alternative to RMI

[JvlShiz(fail)]

Hi guys, I present the newest version of my RPC library

http://idgames.net/uploads/RPC_Release.rar

It features a client and server hub which can interact via RPC messages.

To understand why this is useful, you need to understand how RMI works.

In RMI, you call a remote function by extending UnicastRemoteObject and implementing each function that you require in RMI, for example:

public interface MyRemote extends Remote {
    public void myMethod() throws RemoteException;
}

public class MyRemoteObject extends UnicastRemoteObject implements MyRemote {
    public void myMethod() throws RemoteException {
          System.out.println("Remote method called");
    }
}

The same code in RPC would look like so:

Server:

RPCServer server = new RPCServer(1919, new DefaultRPCMessageEncoder(), new DefaultRPCMessageDecoder());

server.registerRequestHandler(new RPCRequestHandler() {
			public void handleRequest(RPCClientContext client, RPCMessage request, SeekableLittleEndianAccessor slea) {
System.out.println("Remote method called");
			}
		}, 1);

Client:

RPCClient client = new RPCClient(new InetSocketAddress(InetAddress.getLocalHost(), 1919), new DefaultRPCMessageEncoder(), new DefaultRPCMessageDecoder());
DefaultRPCMessage request= new DefaultRPCMessage();
			request.setRequestID(RequestIDGenerator.getRequestID());
request.setProcedureID(1);
client.callRequest(request);

The above implementations of RMI and RPC will do the same thing, however the RMI version blocks the thread (the thread stops) until a response is received. The RPC version on the other hand, simply sets up a listener and when a response is received the listener is notified asynchronously.

Now imagine if we had to send a character's info across servers.

In RMI:

myRemoteObj.sendCharacterInfo(myCharacter);

in RPC:

PacketWriter pw = new PacketWriter();
pw.writeString(myCharacter.getName());
pw.writeInt(myCharacter.getID());
DefaultRPCMessage req = new DefaultRPCMessage();
req.setBytes(pw.getBytes());
req.setProcedureID(2);
client.callRequest(req);

Now, the problem here is that the RMI version sends a lot of useless info, such as class names and each of the other values in myCharacter that aren't marked as transient.

The RPC version in contrast only sends the required info, such as the name and the ID.

The other downside to the RMI version is that an object of the exact same class will have to be constructed on the receivers end. The RPC version is not so. For example, if you send myCharacter on the senders end in RMI you have to also have the same class available on the receivers end or else you'd get a ClassNotFoundException. In RPC, you can just read the name and ID and construct a smaller object that doesn't require so much space.

An example is included in the download:

net.idgames.server.rpc.test.TestRPCClient
net.idgames.server.rpc.test.TestRPCServer

The example shows how to interact between RPC clients and RPC servers and how to handle responses and requests.

Well I hope at least somebody makes use of this.

- David

[MentaL]

[jon5477]

Nice work bro.

Now this is what I mean by your abilities for getting a PhD.

[Axeroth]

Good job man :)

[Fraysa]

All of you say "Good job" or "Thanks" but none of you don't even know what it is.
Posted via Mobile Device

[JvlShiz(fail)]

All of you say "Good job" or "Thanks" but none of you don't even know what it is.
Posted via Mobile Device

I described what it is.

[AuroX]

umm, By reading your post, i still don't get what is it..could you explain more on what does this do and what's the benefits of using this?.. O.o..confused.

Thanks in advance.^^

[aviv]

what it is doing? :S

[JvlShiz(fail)]

umm, By reading your post, i still don't get what is it..could you explain more on what does this do and what's the benefits of using this?.. O.o..confused.

Thanks in advance.^^

RMI is Sun's Java remoting protocol, Remote Method Invocation.

There are a few downsides to RMI:

• The same class must be available on both the sender and receiver
• RMI uses Object(Input/Output)Stream, which serializes unimportant data such as class names and every other field in the object you're trying to send not marked with transient
• RMI is synchronized, this means when you invoke RMI the thread will block until a response is received
• RMI uses more bandwidth than it should.

Now let's break it down.

RMI encodes objects by serializing them into a stream then sending the stream across the network. RMI uses a special Java object format which actually uses more bandwidth than it should.

RPC by contrast encodes objects with user specified code, which means you only send what you NEED.

RMI decodes objects using their class definition. This means that the same class must be available on the receivers end in order to decode.

RPC by contrast decodes object with user specified code, which means you don't even have to create a new object if you're transferring just a small value or whatever.

RMI is synchronized. The thread which invoked RMI will wait until the receiver tells it to proceed.

RPC by contrast is asynchronous. The thread which invoked RPC will set up a listener that will be notified when the receiver sends a response back (If it does).

RMI uses a predefined format, this means that a lot of useless info is added to the stream.

RPC by contrast uses a user defined format. This means you can control how much bandwidth it uses.

I hope this helps.

[AuroX]

Thanks a lot, now i get it..lols.. So RPC is basically another method which has better benefits used to replace RMI?

[JvlShiz(fail)]

Yep. An asynchronous faster alternative to RMI.

[Wingx]

Anyway , can someone explain a little easy about this <RPC> ,Sorry i never understand this

[Shawn]

Anyway , can someone explain a little easy about this <RPC> ,Sorry i never understand this

.............................................

2 posts above yours bro.... 2 posts...

RMI is Sun's Java remoting protocol, Remote Method Invocation.

There are a few downsides to RMI:

• The same class must be available on both the sender and receiver
• RMI uses Object(Input/Output)Stream, which serializes unimportant data such as class names and every other field in the object you're trying to send not marked with transient
• RMI is synchronized, this means when you invoke RMI the thread will block until a response is received
• RMI uses more bandwidth than it should.

Now let's break it down.

RMI encodes objects by serializing them into a stream then sending the stream across the network. RMI uses a special Java object format which actually uses more bandwidth than it should.

RPC by contrast encodes objects with user specified code, which means you only send what you NEED.

RMI decodes objects using their class definition. This means that the same class must be available on the receivers end in order to decode.

RPC by contrast decodes object with user specified code, which means you don't even have to create a new object if you're transferring just a small value or whatever.

RMI is synchronized. The thread which invoked RMI will wait until the receiver tells it to proceed.

RPC by contrast is asynchronous. The thread which invoked RPC will set up a listener that will be notified when the receiver sends a response back (If it does).

RMI uses a predefined format, this means that a lot of useless info is added to the stream.

RPC by contrast uses a user defined format. This means you can control how much bandwidth it uses.

I hope this helps.

[mertjuh]

I've never worked with RMI or RPC or whatever.
What do you recommend if you're new to this and want to learn from scratch?

[King Grub]

For RMI, go here.

[Carrino]

This is useful, I will make use of it, it makes my job more easier.

Thanks David/Jvlaple!