Genora has pioneered high end chat applications development using xmpp architechture. Here is a detailed report you need to know while developing chat applications. Reach us at https://www.genorainfotech.com/

1. ​Project Report

2. Index:-
1.​XMPP architecture Diagram.
2​.Scribble Feature.
3.​Multiple Point of Presence Support for XMPP.
4.​Support for BlackBerry/Windows/J2ME.
5​.Load testing Scenarios.
6.​SIP v/s XMPP.
7.​VOIP/Video Support.
8.​OpenFire Scalability.

3. XMPP Architecture
Scribble Feature:-
The app wou​ld have a unique feature that would help it stand out in front of its Competitors.
The user can choose to scribble the message over a notepad included in the app and the same
pattern would be send across to the recipient and it would be re-produced on the recipient’s
screen as well.
Working:-
● The user will be a provided with a Pre-defined space where he will be allowed to doodle.
● The user can draw a pattern and click on send.
● The recipient’s screen will then re-produce the pattern using highly sophisticated
algorithms and caching techniques.
Multiple Point of Purpose support for XMPP:-
XMPP allows for Multiple Point of Purpose support(MPOP).The user can Log-n and check his
messages through multiple devices. This is implemented using the following process:-
● Each Device is provided with a Resource identifier and a Priority Number.

4. ● Incoming messages are routed to the resource with the highest priority number.
● Messaging a Particular resource can be done by using XMPP address.
Support for BlackBerry/Windows/J2ME:-
XMPP and Openfire has extensive support for BlackBerry/Windows and J2ME.Native Apps in
Blackberry are developed in Java .Native Apps in Windows are coded using C#.XMPP and
Openfire are compatible with Java and XMPP.J2ME apps are developed using Java and will
support XMPP and Openfire Support. Blackberry and J2ME can be developed using the support
of Jabber Stream Objects(JSO) library. Windows app can be developed using Jabber-net library.
Load testing Scenarios:-
Performance Test Scenarios
Login
1. Login with 20000 Virtual Users at the same time and check the server response. Increase
the limit and find the maximum number of users that can login at a particular time.
2. Login with 1000 Facebook Virtual Users at the same time and check the server response.
3. Repeat the above mentioned test case for Twitter and Google Accounts.
Registration
1. Scenario 1: Register 20000 virtual users without uploading profile image and check the
response time.
2. Scenario 2: Register 20000 virtual users by uploading profile image and check the
response time.
3. Check the maximum number of users the server can handle.
Group Listing – Explore
1. Load 10000 groups with their respective group symbol and check the server response.
2. Send 10000 private groups join request to the admin and check the upper limit for
maximum request. Request must be sent to all the group admins.
Contact Listing – Explore
1. Load 100 Contacts with their respective Profile picture and check the server response
time.

5. Group Listing and Contact Listing– Home page
1. Find the average time to load 100 groups and contacts.
2. Login of user on new device, User who is the part of at least 50 groups and check the
server response time
Measuring performance for transfer of messages
Assumption: Full network connectivity
1. Average time taken to transfer text message (30 messages)
Test Case 1
Transfer 100 text messages, each 20KB, from client 1 and client 2. For each transfer
capture (in a tabular form)
a) Latency between client 1 and server
b) Latency between server and client 2
c) Total time taken from the moment the message is sent from client 1 and received by
client 2
Run the above at 3 different times
Determine average time taken to transfer 100KB data
Expected Result
- The average time taken for message transfer should be in seconds (<5 seconds)
- No messages are lost
- The messages are received in the order in which it was sent
Test Case 2
Repeat Test Case 1 for audio/video message – 10 messages each 1MB
Note: Audio and Video messages are sent as links. The user can then choose to
download the file.

6. Test Case 3
Repeat Test Case 1 for geographically distributed clients
Test Case 4
Repeat Test Case 2 for geographically distributed clients
Test Case 5
Simulate processing of 1000 messages at once in a group (1000 concurrent users).
Check if server performance is stable. Keep on increasing this number and determine
the optimal performance in terms of CPU and memory

7. SIP vs XMPP
The following table lists the crucial differences between the two sets of protocols.
SIP XMPP
Purpose
Provide rendezvous for session
establishment and negotiation where the
actual session is independent, e.g., over RTP
media transport.
Provide a streaming pipe for structured
data exchange between group of clients
with the help of server(s), e.g., for instant
messaging and presence
Protocol
Text-based request-response protocol
similar to HTTP, where core attributes are
signaled using headers, and additional data
using message body, e.g., session description
of capabilities.
XML-based client-server protocol to
create a streaming pipe on which it sends
request, response, indication or error
using XML stanza between client and
server, and between servers.
Transport
Usually implemented in connection-less UDP
as well as connection-oriented TCP
transport. Also works over secure TLS
transport.
Works over connection-oriented TCP or
TLS transport.
Connection
A user-agent is both client and server, hence
can send or receive connections, in case of
TCP or TLS. This does not work well with
NATs and firewalls, hence extensions are
defined to use reverse connections when
server wants to send message to client.
The client initiates the connection to the
server, which works well with NATs and
firewalls. Additionally, extensions are
defined such as BOSH to carry XMPP
stanza over HTTP to work with very
restricted firewalls
There are many other differences, e.g., the way a URI is represented, or how authentication is
done, or what kinds of messages are supported. I will not go into details of those since they
tend to become too specific for the kind of application and we miss the important points. From
a developer's point of view 'ease of programming' is very important.
Ease of programming
There are two main reasons for SIP's difficulty among developers: (1) the emphasis of SIP is on
interoperability rather than application and feature design, and (2) the emphasis in SIP
community is to have one protocol solve one problem, which requires implementing a plethora
of protocols for a complete system. Let me explain these further.
SIP system incorporates other external mechanisms such as STUN, TURN, ICE,
reverse-connection-reuse and rport-based symmetric request routing to solve the NAT and

8. firewall traversal problem, and still does not guarantee media connectivity in all scenarios
unless HTTPS/TCP tunnel in used. Implementing instant messaging and presence involves
implementing several RFCs and drafts related to Event, PUBLISH, CPIM, PIDF, XCAP, MSRP, and
still the application does not have all the features of commonly available XMPP client. In
summary the SIP community has created numerous extensions for solving several problems
Scalability and performance
SIP is inherently a peer-to-peer protocol whereas XMPP is inherently client-server. Tasks that
are easy in client-server systems such as shared state, roster storage on server, or offline
messages on server, are well accomplished with XMPP.In XMPP, server is a must and all
signaling communication goes through the server. There are message semantics defined for the
types of messages, e.g., client-server information query, client-server-client message sending,
client-server event publishing and server-client event notifications. Clearly client-server
applications are limited by scalability and performance of the server. For example, an instant
messaging session need not go through the SIP server saving bandwidth and processing at the
server.
It works with a lot of clients, and as far as I can tell SIP seems to come from LAN/Linux thinking.
These are the clients Jabber work with. It includes everyone, including SIP for one big happy
family. It works with a ton of servers and has scads of libraries.
The clients are listed below, which is quite an extensible and scalable list.
​Apple MacOS
Console / Text-Mode​?
Cross-Platform​?​(Linux/Mac/Windows)
Linux/Unix
Microsoft Windows
Mobile Phone / PDA
Web Browser

9. Apple MacOS
* Adium
* iChat
Console / Text-Mode
* climm
* Finch
* GNU Freetalk
* irssi-xmpp
* mcabber
Cross-Platform (Linux/Mac/Windows)
* Coccinella
* Jabbim
* JBuddy Messenger
* Jeti
* Oyo
* Pidgin
* Psi
* qutIM
* saje
* SIP Communicator
* Spark
* Tkabber
* Tlen
* Vacuum
Linux/Unix
* Ayttm
* BitlBee​?
* Empathy
* Gajim (also Windows)
* Galaxium
* Gossip

10. * jabber.el
* Kopete
* Sim-IM
* Synapse
Microsoft Windows
* AQQ
* eM Client
* Exodus
* glu
* Jabbear
* JAJC
* Miranda IM
* Pandion
* Quiet Internet Pager (QIP)
* SoapBox​?​Communicator
* Trillian Pro
* V&V Messenger
* WTW
* Yambi
Mobile Phone / PDA
* Agile Messenger
* beejive
* Bombus
* BuddyMob​?
* Chatopus
* IM+
* imov Messenger
* Jabber Mix Client
* Jabbim for Android
* Jabiru
* Lampiro
* m-im
* mChat
* OctroTalk​?
* OneTeam​?​for iPhone
* Talkonaut
* Vayusphere
* Yaxim

11. Web Browser
* Afflux
* Claros Chat
* emite
* iJab
* Jabbear
* JWChat
* SamePlace​?
* Slimster
* SparkWeb​?
* Tigase Messenger
* Tigase Minichat
* TrophyIM

12. VOIP/Video Support
Voice over internet Protocol and Video calling can be implemented using Openfire server by
using the Plug-in called “Jingle” developed by Google and XMPP standards foundation.Major
VOIP services such as Skype and Google talk make use of Jingle protocol for VOIP and Video
calls.
Jingle Nodes Plugin
Jingle is an extension to the Extensible Messaging and Presence Protocol (XMPP) which adds
peer-to-peer (P2P) session control (signaling) for multimedia interactions such as in Voice over
IP (VoIP) or videoconferencing communications. It was designed by Google and the XMPP
Standards Foundation. The multimedia streams are delivered using the Real-time Transport
Protocol (RTP). If needed, NAT traversal is assisted using Interactive Connectivity Establishment
(ICE)."
Why Jingle Nodes
In the creation of the very first version of the Jingle Protocol, one of the main goals was to
achieve a P2P enable protocol, that would depend on XMPP for routing, but would be also able
to negotiate sessions and exchange content without main proxy servers like present SIP
deployments.
After 5 years we still don't have any massive deployments containing and fully supported the
current specifications, and even the closer to the specification ones are suffering when P2P is
not possible and relay is required and there is no available ones.
That is the problem Jingle Nodes proposes to solve.

13. Jingle support for Openfire
Sometimes there is no replacement for voice, video, and other rich media ​interactions.
Enter Jingle, defined in and a number of related specifications. After several​​years of
experimentation, in 2005 the XMPP developer community finally got serious​​about adding
support for voice chat, spurred on by the launch of ​Google Talk​, an​​XMPP-based service
for instant messaging and Voice over Internet Protocol (VoIP). In​​fact, the Google Talk
team worked with developers in the community to define Jingle​​as a refinement of the
Google Talk protocol (similar to the way in which XMPP is a​​refinement of the original
Jabber protocol or Multi-User Chat is a refinement of the​​original groupchat protocol​).

14. Jingle provides a reliable mechanism for setting up voice calls over the Internet.Even more
interesting, the same basic Jingle methods can be​​used to negotiate and manage any kind
of media session, including video chat, file​​transfer, and screen sharing. This makes Jingle
yet another powerful building block in​​the XMPP toolkit.
Jingle provides a pluggable model for both application types and transport methods.
Typically,Jingle is used to set up sessions that are not appropriate over XMPP itself. As
we’ve discussed, XMPP is optimized for the exchange of many small snippets of​​XML, not
data-heavy media streams. The Internet community has defined perfectly​​good
technologies for the transport of voice, video, files, and other application types.​​Jingle
therefore simply reuses those technologies for “heavy lifting” rich media sessions.​​The
basic idea is that Jingle uses XMPP as the signaling channel to set up, manage, and
terminate media sessions, whereas the media data itself is sent either peer-to-peer​​or
mediated ​through a dedicated media relay.
Think of Jingle as a way to set up media sessions that go outside the norma l XMPP channel.
The Jingle Model
In a Jingle negotiation, one party (the initiator ) offers to start a session, and the other party
(theresponder) answers the offer by either agreeing to proceed or declining the invitation. An
offer has two parts:
Application type
States what is going to be exchanged in the session—for example, voice chat via the Real-time
Transport Protocol (RTP).
Transport method
Describes how data is going to be sent—for example, using the User Datagram Protocol (UDP).
The offer triggers a flurry of XMPP traffic between the initiator and the responder, as their
XMPP clients negotiate various parameters related to the application type (e.g., audio codecs)
and the transport method (e.g., IP addresses and port numbers to check for connectivity).

15. Once both parties agree on these parameters and the responder sends a Jingle session-accept
message, the session transitions from the pending phase to the active phase. At this point, the
XMPP signaling​traffic quiets down as the parties ex- change media data (XMPP stanzas can still be
exchanged during the active phase as well, for example, to renegotiate parameters, or to add a new
application type such as video to an existing session).
Thus, the overall flow of a Jingle session is as follows:
1.The initiator sends an offer to the responder.
2. The offer consists of one or more application types (voice, video, file transfer, screen
sharing, etc.) and one or more transport methods (UDP, ICE, TCP, etc.).
3. The parties negotiate parameters related to the application type(s) and work to set
up the transport(s).
4. The responder either accepts or declines the offer.
5. If the offer is accepted, the parties exchange data related to the application type(s)
over the negotiated transport method(s).
6. If needed, the parties can modify certain parameters during the life of the session
(e.g., by adding video to a voice chat or switching to a better transport candidate).
7. Eventually, the session ends and the parties go on with their lives.

16. Jingle on Interactive Connectivity Establishment(ICE)
Interactive Connectivity Establishment is a powerful methodology for figuring out how to set up
media sessions (such as voice and video calls) over the Internet while still respecting the NATs
and firewalls that may exist in a given network. Some NAT traversal methods try to “fake out”
firewalls, and therefore are frowned upon by system administrators, but in contrast, ICE tries to
work with NATs.This “kindler, gentler” approach to NAT traversal requires quite a bit of
up-front negotiation between the parties, as they exchange IP+port pairs for UDP.
But before the parties can communicate that information, they need to create their preferred
list of candidates. There are four candidate types (see the ICE specificationfor complete details):
Host
This isan IP+port hosted on the device itself (e.g., as obtained via Ethernet, a Wi-Fi
hotspot, or a VPN).
Server reflexive
This is an IP+port for a party’s device, but translated into a public IP address by a​​NAT
when the party sends a packet through the NAT to a STUN server or a TURN​​server. The
party then discovers the server reflexive address for a specific candidate​​by contacting the
STUN server or TURN server.
Peer reflexive
A peer reflexive candidate is similar to a server reflexive candidate, except that the mapping of
addresses happens in the NAT when the party sends a STUN binding request to a peer instead
of directly to a STUN or TURN server. The party discovers the peer reflexive address as a result
of connectivity checks later in the negotiation process.
Relayed
This is the IP+port of a relay server (e.g., as hosted by an ISP). Typically, such a​​relay
implements TURN, but it could implement some other data-relaying​​technology.Once a
Jingle client gathers these candidates, it prioritizes them according to the ICE​​rules, and
then includes its highest-priority candidates in the session offer it sends to​​the responder.

17. Openfire Scalability
This document gives an overview of how the Openfire team recently increased the server's
scalability by reworking the server's networking layer as well as by optimizing existing code.
The details given here reflect tests on a modest deployment; for example, connection
managers were not used. Tests on a framework that's closer to real-world usage promise to
show even more dramatic improvements.
Summary
In early tests, Openfire developers have demonstrated a server scalability improvement from
an approximate 6,000-user maximum in version 3.1.1 to more than 50,000 concurrent users in
version 3.2 at one particular node. ​NimBuzz chat has made use of multiple nodes and have
gone onto support 150 million users ​.Openfire achieved these improvements through
enhancements in which they:
● Replaced the networking layer with Apache MINA, an open source networking
framework that provided support for asynchronous I/O and a foundation for better
scaling. Through MINA, Openfire server and connection managers make more efficient
use of threads.
● Optimized code to reduce use of performance-expensive APIs and remove
unnecessary processing (such as superfluous user validation and XML parsing).
● Implemented a cache to reduce database queries. Administrators can view cache
usage data from the Openfire admin console.
For business cases that involve extremely high I/O use (such as many group chats, file
transfers, and so on), you will want to use one or more connection managers. For other
cases, simply using Openfire should meet the need.

18. Configuration
Openfire server was deployed to a machine running Sun 280R Server with two 1.2GHz
UltraSPARC-III CPUs, 4GB RAM, fiberchannel disks, and FastEthernet (100Mbit/s). A MySQL
database was used for stored data. An Openfire plugin generated users, populated 40 rosters
with 40 contacts in each, and created vCards. Connection managers were not used; requests
were sent directly from simulated users to Openfire server. Memory assigned to the Java
virtual machine was 2GB; the server consumed 1GB.
IM tests were run using Tsung, software that simulates users. Tsung was run on a
configuration that included two master machines with three slave machines each. The
master machines instructed the slave machines to submit client requests to the Openfire
server machine. These requests included logging in 500 - 800 virtual users per second. The
data requests included authenticating, getting the roster, sending chat messages, and
getting user vCards.
Two sets of load tests were used: one to log in a large number of users with low levels of
activity, and another to generate a fixed load of 1,500 users who are extremely active and
performing resource intensive actions. When one test was failing to add more users to the
system, a second test was launched from two different locations to generate additional load
of 3,000 extremely active users. Openfire was easily able to handle the additional load
generated by these user activities.

19. Test Results
In tests simulating 300 users to 50,000 users , the load was gradually increased on the
Openfire server and the MySQL database.
The following illustration shows performance over a period of seconds. Toward the last
third of the test, group chat testing was activated to increase load. The bottom portion of
the chart shows packet reads and writes as the number of user sessions increases (packet
read/writes occur for exchanges of XMPP stanzas such as IM messages, presence
notifications, and information queries). The chart's top portion shows percentage of se​rver
CPU use for the same period of the test.