Java Instant Messenger questions

Question

I am looking to build an instant messenger in Java.

1. Clients will connect to the server to log in.
2. They will start a conversation with one or more other clients.
3. They will then post messages to the server that will relay the messages to all the clients.

The client needs to be continually updated when users post messages or log in.

so the way I see it, the client needs to run a server itself in a separate thread so that the main server can send stuff to it. Otherwise the client will have to the poll the main server every xyz seconds to get the latest updates. And that would need a separate thread anayway, as that would be purely for getting updates whereas the 'main' thread would be used for when the client initiates actions such as posting messages/inviting others to conversations etc...

So anyone recommendations on how to write this instant messenger? Does it sound like a good idea to make the connection a 'two-way' connection where both the client and server act as servers? Or is polling a better option? Anyone know how the IRC protocol does this?

Answer 1

There's no real advantage of having 2 connections unless they can be handled independently (for example receiving / sending a file usually done in a separate connection). A connection itself is already a two-way communication channel so it can be used to both send and receive messages, events etc. You don't need to poll server since client is able to maintain persistent connection and just wait for data to appear (optionally sending periodic PING-like message to ensure connection is alive).

IRC uses a single connection to server to exchange text commands. For example one of the main commands:

PRIVMSG <msgtarget> <message>

This command can be originated either by client or by server. Client sends PRIVMSG to notify that it wants to deliver message to one or more destination (in IRC this either user(s) or channel(s)). Server's task here is to properly broadcast this message to appropriate clients.

Answer 2

If you're using raw InputOutput streams then yes this is a good way of doing it. You create one thread on the clientside that acts in a similar fashion as the server thread - waits for any incoming updates and when it does it updates the client. I wouldn't call it a server though. So you'd ideally have 2 TCP/UDP connections one for requests made by the client and one to notify the client of server changes.

This solution in an enterprise environment would probably be done through some kind of messaging framework such as Spring Integration but dig deep enough and it will essentially be a similar way to how you mentioned.

Answer 3

Do you need a fully custom protocol or would it be sufficient to use the XMPP? There are several open source libraries implementing XMPP. http://xmpp.org/xmpp-software/libraries/

e.g. http://www.igniterealtime.org/projects/smack/

Answer 4

For me, to develop instant messaging service, I will use websocket protocol instead of normal java socket because the normal socket can not work well with HTTP protocol and moreover some network providers and firewalls banned custom ports. If you develop it in normal socket, your service could not be accessed by web clients.

Did you plan to develop the instant messaging service yourself? How about using other protocols such as Jabber?