RTalk

RTalk is an IM client based on the Rediff BOL protocol.

General

1. RTalk

RTalk is an instant messenger client for the Rediff Bol protocol designed to run on the Java platform. RTalk is graphical and uses the Swing toolkit for its user interface.

2. What are the requirements to run it ?

A Java 6 runtime. The runtime needs to be update-1 or above (which has this bug fixed.)

3. How do I run it ?

If your system is configured to load and run jar files, double click on the jar file from your UI. Otherwise open a console and execute "java -jar RTalk.jar". You can also view program output (and exception traces !) in the console that way. For building, you will need SE6 JDK. Use a subversion client to get the code, and use ant to build.

svn co https://rtalk.svn.sourceforge.net/svnroot/rtalk/trunk rtalk
cd rtalk
ant

4. Will this work on Linux ?

Yes. RTalk is 100% pure Java. You will need to have a correctly configured Java 6 runtime. If you have Compiz Fusion enabled and see gray windows, please see this bug for more info.

5. What works ?

Your mileage may vary. As there are large holes in my understanding of the protocol and as well that Rediff can modify their protocol, it is probable that things break. Implemented so far are 1-1 chat, buddy management, chat rooms functionality and several others.

For Developers

1. How do I contribute/contact you ?

Please contact me via SourceForge (binu_paul@users.sourceforge.net).

2. How can I reverse engineer the protocol ?

To see what's going on, I use Wireshark on a Windows box running RBol. The protocol is binary (as opposed to a text based protocol), so it is harder to see what is going on.

3. Why JRE 6 ?

RTalk uses SwingWorker.

4. Can you summarize the protocol ?

I am planning to document my understanding of the protocol here. Meanwhile, have a look at the source code to know more. Here's my attempt at a summary though:

• Connection: Connection is made over port 1836 (the same one used by MSN). There is a server (for load balancing?) which the client first connects to, and which that tells the client where to connect again and send the login credentials. There is no token from the first connection (unlike some other IM systems), so a badly behaved client can even igore the first step. The credentials are send in plain text (surprise!).
• The nature of the protocol: There are no acknowledgments for operations with success outcomes. There is a keep-alive mechanism where by the client needs to send the 'heart-beat'. The server disconnects if it does not get the heart-beat in time.
• What the client uses: The client uses a mix of HTTP and the proprietary protocol. HTTP is used for displaying 'avatar' images, and for checking if a nick-name exists, among others.
• The actual protocol: As an example, look at what the client sends while I delete a buddy:

  00000000  4e 00 00 00 03 00 00 00  09 00 00 00 53 65 72 76 N....... ....Serv
  00000010  65 72 31 2e 32 0b 00 00  00 44 65 6c 43 6f 6e 74 er1.2... .DelCont
  00000020  61 63 74 32 2a 00 00 00  07 00 00 00 46 72 69 65 act2*... ....Frie
  00000030  6e 64 73 1b 00 00 00 62  62 5f 63 79 62 65 72 64 nds....b b_cyberd
  00000040  79 6e 65 40 72 65 64 69  66 66 6d 61 69 6c 2e 63 yne@redi ffmail.c
  00000050  6f 6d                                            om
  

  And here's the analysis

  Data				length
  4e 00 00 00			4	value = 78 (total length of the data that follows)
  03 00 00 00			4	value = 3 (hardcoded constant)
  09 00 00 00			4	value = 9
  Server1.2			9
  0b 00 00  00			4	value = 11 (b in hex)
  DelContact2			11	
  2a 00 00 00			4	value = 42 (2a in hex) This is the length of the data that follows. (4+7+4+27)
  07 00 00 00			4	value = 7
  Friends				7	
  1b 00 00 00			4	value = 27 (1b in hex)
  bb_cyberdyne@rediffmail.com	27	This is the buddy to be deleted
  

  The key to understand the protocol is that the length of the data is prefixed to the data.

5. Is there a Pidgin plugin ?

For a Pidgin plugin project (by Arnold Noronha) that uses HTTP (instead of the RBOL protocol) look at rediffbol-prpl.