Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Chat Messenger  RSS feed

 
rajesh karmani
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As i have heard its better to design a messenger based on RMI rather than writing a custom protocol using sockets or is it the other was round?
Can somebody clarify in that regard?
 
Roy Ben Ami
Ranch Hand
Posts: 732
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
depends on what is easier for you....
usually , for beginners i'd recommed using sockets because it is very easy... BUT if you know RMI then use it!
thats what it was desgined for .
 
Shubhrajit Chatterjee
Ranch Hand
Posts: 356
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think RMI is much easier ... just take a small effort to learn it !!!
Sockets will be easy to start with but then with a complicated system , you will have to develop custom protocol , which will be a big task.
 
Iain Shigeoka
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
RMI is great if you can guarantee Java at both ends of the conversation. You can use RMI-IIOP to talk with RMI on one end to CORBA at the other end but that introduces some complexity.
One serious down side with RMI is talking over firewalls. This is something RMI doesn't handle very well at all. Although there are producuts like RMI Proxy (www.rmiproxy.com) that allow you to proxy RMI through a firewall.
Another is security. RMI is really designed for lan connections over a semi-trusted network. Denial of service attacks for example are really effective against RMI. You can use code signing to protect RMI to some degree but there are many aspects of the technology that simply aren't ready for direct Internet exposure.
RMI over a VPN though pretty much solves these problems if you can establish a trusted VPN between communicating parties.
Jini (Java distributed computing framework see www.jini.org) ran into these problems because it was based on RMI communication. The Jini team at Sun is working on the next generation Jini system which includes a competely reworked RMI sub-system with all these issues being addressed (security, proxying, etc). Since the Jini team is composed of most of the members of the original RMI team (and the original RMI team composed of many of the original CORBA team), there is a good chance that this next generation RMI being developed for Jini will eventually work its way back into the standard Java libraries (or at least be a new rmi like nio is the new (nonblocking) io library).
if you want to take a sneak peak at this new RMI, check out the overture project at www.jini.org. overture is the early access codebase for Davis (that next generation Jini release).
-iain
 
Michael Zalewski
Ranch Hand
Posts: 168
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by rajesh karmani:
As i have heard its better to design a messenger based on RMI rather than writing a custom protocol using sockets or is it the other was round?
Can somebody clarify in that regard?

It kind of depends on exactly what you are trying to do.
Will both ends be using Java? Is there a specific type of message object that you can use to contain your message? Can you process the message through relatively few functions, such as receiveMessage, joinDiscussion, makeChatRoom?
If yes, these are things that would make me lean toward RMI.
Are you trying to interface with other network protocals such as AIM, Jabber, IRC? Are you writing a server which needs to be scalable and support hundreds or thousands of users? Do you want non Java clients to have access to your protocol? Do you want to tunnel your messages through a firewall?
If yes, these are things that would make me lean toward sockets.
If the protocol needs to be rich and complex, it is probably better to try and use something that already exists. Other choices besides RMI might be IRC, SOAP, etc.
Designing a low level socket implementation of a complex protocol is kind of like designing your own B-Tree file system. You could do it, and it will probably be very efficient and fast when you get it finished. But if you re-use an existing higher level technology, your solution will be more adaptable to change.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!