Instant Messenger Application Architectures

Instant messenger applications such as ICQ and MSN Messenger, allow users to communicate directly with each other and in an instantaneous fashion. The main capabilities of such systems include:

• Peer and User Discovery - Allowing peers and users to discover and be aware of each other
• Peer and User Communication - Allowing peers and users to communicate with each other
• Peer and User ID - Allowing peers and users to be uniquely identified on the network
• Security - Providing security within the system
• Data Management - Allowing data to be stored and managed on the peers
• User Interface - Allowing for the creation of an Instant Messenger user interface for the peers
• Network Structure - Allowing for the creation of de-centralised and semi-centralised systems

Semi-centralised: Server Node

Instant messenger applications have a high dependency upon awareness monitoring as users of the system need to be aware of the status of other users. It would be possible to incorporate awareness within the P2P Network Layer but for this type of application it would be more suitable for it to remain separate and at a higher level to increase its visibility to developers. Awareness could also be tied to incoming communications. For example, if the server receives a communication from a peer that it previous thought was off-line, then it can update its records accordingly. Aside from this server architecture will operate in a similar way to the generic server discussed previously.

Figure 1 - Instant Messenger Server Architecture

Server peer Layers

• Server Control/GUI

• Repository Manager
• Checking in/out data
• Awareness Monitor
• Authentication
• Message Resolver
• P2P Network Layer

• Network Interface

Semi-centralised: Client Node

The client node possess the mechanisms and interfaces for user-user communication. Given the importance of awareness in such a system the client version’s Awareness Controller is likely to be tightly coupled with the Awareness monitor running on a server. Aside from this client architecture will operate in a similar way to the generic client discussed previously.

Figure 2 - Instant Messenger Client Architecture

Client peer Layers

• Application/GUI

• Awareness Controller
• Message Resolver
• P2P Network Layer
• Network Interface

Decentralised Node

Large scale decentralised instant messenger applications are unlikely to be feasible due to the restrictions posed by the network (i.e. not all peers being able to connect to each other, portioning, QoS issues, etc). However, for smaller scale (and especially direct communication architectures) it may be possible to support such a system. A decentralised node in such an architecture would essentially be the same as a client node (detailed above), but with provision for the publishing and discovery of peer/resource adverts, and for the routing of messages. One issue that will certainly need to be considered is how users of the system can be provided unique ID’s.

Figure 3 – Instant Messenger Decentralised Architecture

Decentralised peer Layers

• Application/GUI

• Awareness Controller
• Message Resolver
• P2P Network Layer
• Network Interface