Sockets vs. RMI

[Daniel Simpson]

Hi, I am beginning my design process for the SCJD and I am deciding whether to use sockets or RMI in my application. What have you guys been using, and what are the pros and cons of each? Thanks!
[ November 04, 2004: Message edited by: Daniel Simpson ]

[Wim van Haaren]

Hi Daniel,

I have chosen to use RMI mainly because RMI hides the details of object serialization and network communication whereas otherwise you have to implement it all yourself. This also has the pleasant advantage that the amount of code you have to write is reduced drastically. RMI furthermore is a standard protocol which makes your code that uses RMI easier to understand (and maintain) by others.

On the downside however, because RMI is a standard protocol, it isn't as flexible as a non-standard custom-written solution might by. An other con might be that RMI is Java only. So if you have a non-Java client it can't use your server, but luckely this is not the case for this asignment .

For this assignment I would say that RMI is definitively the way to go.

Grtz,

Wim van Haaren

[Andrew Monkhouse]

Hi Daniel,

It seems that whenever this question is raised, most of the replies seem to come from those who have chosen RMI. So I will leave them to give you reasons for RMI, and I will discuss some of the Sockets advantages.

RMI requires you to run multiple server applications (the RMI Registry plus your real application) while a sockets solution only requires the one server application.

RMI requires one more port to be used (the standard RMI port is 1099), while a socket solution only needs one port. Note however that this can form part of an argument for RMI: each sockets solution must use it's own dedicated known port number, while all RMI applications share the one common RMI port, then the individual servers can have randomly assigned ports (which is easier for administrators).

A simple method call using RMI will result in more network traffic than the same method call using Sockets. In my (extremely rough) experiments I have seen RMI sending 10 * as many bytes for a simple method call compared with my tuned sockets solution. Similarly the network traffic needed just to make the initial connection is pretty amazing.

And one argument which is valid: some people may already have a wealth of experience with Sockets, but know nothing about RMI. In which case it may make sense to use Sockets. Personally I think that SCJD should be a learning experience, so if you don't know RMI and/or you don't know Sockets, now is a good time to learn them so that you can make informed decisions. But in the real world you may find that you just don't have time for this - if the boss is expecting your software to be delivered at the end of next week, you may have to go with the technology you know best.

My thoughts on some commonly stated reasons for RMI / Sockets:

"RMI is easier for the junior programmer to understand than Sockets". Personally I am not convinced of this - I have seen too many really bad RMI solutions to accept that argument. A good sockets solution can be just as easy to understand, and if abstracted properly the junior programmer will not be any more aware of it than they are aware of the details of RMI.

"RMI is Java centric while Sockets is application / language agnostic". RMI is only Java centric while using RMI/JRMP (which we must do for this assignment). But if you use RMI/IIOP (which you can't do for this assignment) then you get interoperability with CORBA. Likewise pure Sockets are application / language agnostic, however this assignment requires us to use Serialized Objects over Sockets, which brings back our dependency on Java (although technically speaking it would be possible to write your client in another language and do some specific conversion in/out of Java serialized objects since the specification for them is readily available).

Regards, Andrew

[jiju ka]

Another two reasons I got from this forum on favouring RMI are

RMI uses sockets and sun want us to use libraries which are already available. (I don't fully agree with this statement since if we use sockets it will not be like we are reinventing RMI).

RMI handles threading issues and sockets don't. Socket programmer needs extra work to handle it. I favor to use RMI than sockets only because of threading issues. But I like to learn sockets.

[peter wooster]

Originally posted by Daniel Simpson:
Hi, I am beginning my design process for the SCJD and I am deciding whether to use sockets or RMI in my application. What have you guys been using, and what are the pros and cons of each? Thanks!

[ November 04, 2004: Message edited by: Daniel Simpson ]

I started using sockets, because I know that area very well, I've since moved to RMI as a learning experience. Here are some reasons to use sockets:
- sockets are more efficient in network usage
- sockets give you more control
- a socket server can change port without having to restart
- your socket server can detect lost connections without having to set java system properties
- you can run 2 servers on the same machine, and actually switch between them
- sockets provide a great opportunity to use the GoF Command pattern

All that said, I'm still using RMI.

[peter wooster]

Originally posted by jiju ka:
Another two reasons I got from this forum on favouring RMI are

RMI uses sockets and sun want us to use libraries which are already available. (I don't fully agree with this statement since if we use sockets it will not be like we are reinventing RMI).

RMI handles threading issues and sockets don't. Socket programmer needs extra work to handle it. I favor to use RMI than sockets only because of threading issues. But I like to learn sockets.

Threading in socket servers is actually very simple. There is a thread that accepts connections and a thread that performs commands and returns responses for each connection (you need 2 thread if you want full duplex). You can associate a client with a connection, a business operation with a connection or a single command with a connection. Its up to you.

The obvious model for this assignment is the connection per client model. This works well when there are a small number of clients, its very efficient but it doesn't scale very well. It does mean that each client is represented on the server by a thread which remains the same for every command. This is not the case for the other two models or for RMI.

The connection per command model is less efficient for small numbers of clients, but scales much better. Its the model used by Web servers. In this model, you need to build some kind of session tracking, if you have used HTTP you are aware of this issue.

The connection per business operation is in between, it scales well and it tracks session for the sequence {connect,lock, read, update, unlock, disconnect}. Its the model I was using before switching to RMI.


If you know RMI and not sockets, I'd recommend you do the opposite of what I did. Once you have RMI working, save your work and give sockets a try.
/peter

[James Clinton]

If you want to start using sockets, I suggest writing a noddy chat server. I think IBM and Java have tutorials on there sites.

[Daniel Simpson]

Thanks a lot! I've done a little bit of work with sockets but I may give RMI a try from all of your ideas and reasonings. Thanks!