3

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?

Jim_CS
  • 4,082
  • 13
  • 44
  • 80

4 Answers4

1

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.

alex.p
  • 2,627
  • 17
  • 28
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.

pingw33n
  • 12,292
  • 2
  • 37
  • 38
  • You say I dont need to poll server but how can I just 'wait for data to appear'? The client needs to send a request to the server for the server to respond. That is why I was thinkig of using two connections, so that the client wouldnt have to poll the server with requests to receive updates. – Jim_CS Feb 07 '12 at 12:39
  • 1
    @John McDonald If client is keeping connection open it doesn't have to do any special requests for updates. Going down to the lower layer the requests and responses are sent and received with normal read-write operations on the socket. The read operation will block the thread until the data arrives (in classic blocking IO). And yes, you might call it "long polling" though it's mostly related to HTTP-only communication where sockets are not available directly. – pingw33n Feb 07 '12 at 13:26
  • OK say I use just the one connection for the client as you suggest - and as you also say the read operation will block the thread waiting until data arrives.Where I have the issue is that if the read operation which is listening for updates is blocking, how can the client send requests to the server? Are you saying make two threads use the one connection? So have one thread that blocks on reading updates from the server, and have the other thread that will be used to send requests to the server such as 'logging in'/'add friend'/'send message'? Can two threads use the one connection? – Jim_CS Feb 07 '12 at 19:59
  • @John McDonald Yes, multiple threads can read from or write to a socket ensuring that no multiple same operations will ever occur in different threads in any moment of time. – pingw33n Feb 07 '12 at 21:21
0

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?

FranXho
  • 736
  • 7
  • 18
0

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/

Jan Henke
  • 875
  • 1
  • 15
  • 28