LÖVE

marcosmfilho wrote:I can not put generic ports for clients, the client port has to be the same as the server port to work, so I can not differentiate the clients.

Typically, you'd have the server generate a unique session id for the client. The first remote proc you'd call would be something like "startSession," which would return the session id. Then the rest of the remote procs, or most of them, will take that session id as the first argument.

marcosmfilho wrote:The message should arrive instantaneously on client 2 without it having to make any calls

This isn't really how RPC works, unfortunately. It's a request-response model, meaning the client always initiates communication. The server can't "call up" a client later to deliver a message, it can only respond to requests from clients when those requests are made (like the web).

The usual solution to that is polling. Just have the client ask the server if there are any new messages for it a few times per second.

Remember he is doing this for exercise in college.
So in RMI you can do somethign like:

Client1:
server.registerMessageListener(messageListener)

Client2:
for ml in server.getAllMessageListener() do
ml.send("blabla")
end

And then the message is sent directly to Client1 and never over the server. (Which will cause problems when some Clients are behind an NAT Router)

Well, I guess you could also run a server on each client, it sounds like that's what RMI is doing. I think it will be more work than a dedicated server / pure client setup with polling, and doesn't really represent a "traditional" RPC setup.