Packages
cscie258.TWeitz.proj  

 




Ted I Weitz M.D.

Faculty of Art and Sciences
Extension School
Harvard University

 

Jabber Instant Messenger

Final Project


CSCIE 258
Implementing Internet Protocols




 


 Viewed Best with IE

 

 

See:
          Description

Introduction:

This project is an instant messenger client that implements Extensible Messaging and Presence Protocol EXMP utilizing the Jabber protocol.

The Extensible Messaging and Presence Protocol (XMPP) is an open XML protocol for near-real-time messaging, presence, and request-response services. The basic syntax and semantics were developed originally within the Jabber open-source community, mainly in 1999.  In 2002, the XMPP Work Group was chartered at the Internet Engineering Task Force (IETF) with developing an adaptation of the Jabber protocol that would be suitable as an IETF instant messaging and presence technology.

Jabber is an open XML protocol for real-time exchange of messages and presence between any two points on the Internet. The first application of Jabber technology is an asynchronous, extensible instant messaging platform, along with an IM network that offers functionality similar to legacy IM systems such as AIM, ICQ, MSN, and Yahoo.  Due to the nature of XML the protocol is written in it offers an unlimited potential for extensibility  that can be used for communication between any two parties connected to network. The parties can use the protocol for communication over the Internet or Intranet where the parties can be humans machines or specialized software agents - bots as they are known in the network community.

A Quick Example taken from the Jabber Software Foundation™ Overview

The architecture of Jabber is extremely similar to that of the most time-tested messaging system on the planet: email. While there are some key differences, if you think of Jabber as "instant email" you won't go far wrong. So how does it really work? To understand how, let's first look at a quick example...

There is a tradition in Jabber documentation of using examples from Shakespeare, so let's think about two Shakespeare characters and how they exchange Jabber messages -- perhaps Romeo and Juliet in the famous balcony scene. Now Juliet doesn't send a message directly ("peer to peer") to her Romeo, at least not in the Jabber world. Juliet has an account on a Jabber server, and her Jabber address (we call it a Jabber ID or "JID") looks a lot like an email address. Since Juliet is a Capulet, she registers the username "juliet" with the Jabber server running at capulet.com, so her JID is juliet@capulet.com. Similarly, Romeo has an account on his family's server and his JID is romeo@montague.net.

Once Juliet has logged into the capulet.com server, she can send messages to her sweetie. To be precise, here is what actually happens when Juliet fires up the Exodus client on her Windows laptop out on the balcony:

  1. Juliet sends a message addressed to romeo@montague.net
  2. The message is handled by the Jabber server at capulet.com
  3. The capulet.com server opens a connection to montague.net if one is not already open
  4. Assuming that the family elders have not disabled server-to-server communications between capulet.com and montague.net, Juliet's message is routed to the Jabber server at montague.net
  5. The server at montague.net sees that the message is addressed to an actual user named "romeo" and delivers it to the Jabber client running on Romeo's Linux laptop out in the Capulets' orchard
  6. The message pops up in Gabber, and Romeo swoons

There are a lot of pieces here: clients running on different operating systems, multiple servers, a communication channel between the servers, and two star-crossed lovers. Jabber handles everything but the last part. To imprint this process, let's visualize it with a picture:

 

 

A simple network visualization

A simple network visualization

 

Jabber Architectural Foundations

That picture probably looks familiar, because it pretty much captures the architecture of email. Thus communications in email and in Jabber are made possible by a distributed network of servers that use a common protocol, to which specialized clients connect to receive messages as well as to send messages to users of the same server or any other server that is connected to the Internet.

However, whereas email is a store-and-forward system, Jabber delivers messages in close to real time because the Jabber server (and, if permission is granted, other Jabber users) knows when a particular user is online. This knowledge of availability is called presence, and it is the key insight that enables messaging to be instant. Jabber combines these standard IM characteristics with three additional features that make Jabber unique. The first is a fully open protocol. The second is the fact that Jabber's protocol is 100% XML, which makes structured, intelligent messaging possible not only between human users but also between software applications. The third is that Jabber uses addresses that are based on DNS and recognized URI schemes, resulting in addresses of the same form as those used in email (user@host).

The above example is taken from the Jabber Technology Overview under the terms and conditions set forth in the Open Publication License.
It is Copyright © 2000, 2001, 2002 Jabber Software Foundation

 client implementation of a Name Server that communicate via UDP protocol.

 

Resources:

 

Architecture.

The project is using the Smack API and Java Swing for the GUI.  Smack API version 1.01 is currently evolving I modified it slightly when it was needed for my application. 

TedsJabber is the central class of the application. It creates a frame that holds the user information and interactions.  It provides a way to access the users account on the server, sign up with unlimited number of servers and join multiple chat rooms. It allows multiple simultaneous private chats also from the main roster or from each chat room the user joins. It opens a separate
window for each one of these chats.


Using multithreading TedsJabber allows the simultaneous interactions with these chats which relay on the open architecture - non proprietor nature of the Jabber protocol and its wide acceptance as the de facto XMMP standard it brings the world to the users desktop / laptop / portable device.

ChatClient  A class that handles the private chat with individual users. It runs on its own thread so each chat gets
its own thread.

GroupChat A class that handles the chat room chat. It also runs n its own thread.  After instantiating each chat room gets added to the tabbed pane and so allows the user the  interaction with multiple  roomes.  The room lists the room participants from which a participant selection generate a private chat.

AccountSetter   A class that holds the Panel for the account extra information, in the Jabber community this information is referred to as the vCard as the virtual business card.

Account and Login are objects that hold the account and login information.

MyJAB the project interface. It holds the project constants.

WeitzViewer and Its ViewerThread Serves as a costumed Web browser where the Jabber documents are being presented.

Helper is a collection of Swing methods I develop for reuse in my Swing Software toolbox, it is used for the construction of the GUI elements. 

 

Viewing the code.

The Color coded, Indexed Java source code is viewable here

 

Executing the project

Ant the project is using Ant for cross platform compilation. The compile task is the default task for Ant so typing Ant will compile the project.  ant run will run it

 

 

Project Screen Shots and development
 click for detailed images

 

 

 



Running multiple chats and a chat room (debug window on left shows all the packets)

 

 

   



First iteration, using the MUSE API, first connection

 

 

Developing the GUI

 

 



Saturday morning,  Talking with a Russian developer
 

 



Integrating a built-In Web Browser showing the project's own javaDoc

 

 

 


e-me