SlideShare a Scribd company logo
​Project Report
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.
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.
● 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.
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.
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
 
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
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
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
* 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
Web Browser
* Afflux
* Claros Chat
* emite
* iJab
* Jabbear
* JWChat
* SamePlace​?
* Slimster
* SparkWeb​?
* Tigase Messenger
* Tigase Minichat
* TrophyIM
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.
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​).
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).
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.
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.
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.
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.
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.

More Related Content

What's hot

E mail transfer .74
E mail transfer .74E mail transfer .74
E mail transfer .74
myrajendra
 
Simple mail transfer protocol
Simple mail transfer protocolSimple mail transfer protocol
Simple mail transfer protocol
Anagha Ghotkar
 
Dictributed application by Waqas
Dictributed application by WaqasDictributed application by Waqas
Dictributed application by Waqas
Waqas !!!!
 
Lecture 9 electronic_mail_representation_and_transfer
Lecture 9 electronic_mail_representation_and_transferLecture 9 electronic_mail_representation_and_transfer
Lecture 9 electronic_mail_representation_and_transfer
Serious_SamSoul
 
E-Mail - Technical Overview
E-Mail - Technical OverviewE-Mail - Technical Overview
E-Mail - Technical Overview
Venkatesh Iyer
 
Smtp, pop3, imapv 4
Smtp, pop3, imapv 4Smtp, pop3, imapv 4
Smtp, pop3, imapv 4
Shwetanshu Gupta
 
Imap(internet massege access protocaols)
Imap(internet massege access protocaols)Imap(internet massege access protocaols)
Imap(internet massege access protocaols)
shashikant pabari
 
Unit 5 application layer
Unit 5 application layerUnit 5 application layer
Unit 5 application layer
Kritika Purohit
 
Mail server
Mail serverMail server
SMTP - SIMPLE MAIL TRANSFER PROTOCOL
SMTP - SIMPLE MAIL TRANSFER PROTOCOLSMTP - SIMPLE MAIL TRANSFER PROTOCOL
SMTP - SIMPLE MAIL TRANSFER PROTOCOL
Vidhu Arora
 
Performance Evaluation of XMPP on the Web
Performance Evaluation of XMPP on the WebPerformance Evaluation of XMPP on the Web
Performance Evaluation of XMPP on the Web
Markku Laine
 
transfer protocols,ftp,smtp,pop,imap
transfer protocols,ftp,smtp,pop,imaptransfer protocols,ftp,smtp,pop,imap
transfer protocols,ftp,smtp,pop,imap
AKSHIT KOHLI
 
Rpc Case Studies (Distributed computing)
Rpc Case Studies (Distributed computing)Rpc Case Studies (Distributed computing)
Rpc Case Studies (Distributed computing)
Sri Prasanna
 
retrieving the mail
retrieving the mailretrieving the mail
retrieving the mail
tumetr1
 
E mail protocol - SMTP
E mail protocol - SMTPE mail protocol - SMTP
E mail protocol - SMTP
Md Syed Ahamad
 
MSB-Remote procedure call
MSB-Remote procedure callMSB-Remote procedure call
MSB-Remote procedure call
MOHD. SHAHRUKH BHATI
 
Simple Mail Transfer Protocol
Simple Mail Transfer ProtocolSimple Mail Transfer Protocol
Simple Mail Transfer Protocol
Maitree Patel
 
Chapter 2 - Application Layer
Chapter 2 - Application LayerChapter 2 - Application Layer
Chapter 2 - Application Layer
Andy Juan Sarango Veliz
 
Lecture application layer
Lecture application layerLecture application layer
Lecture application layer
Hasam Panezai
 
file transfer and access utilities
file transfer and access utilitiesfile transfer and access utilities
file transfer and access utilities
tumetr1
 

What's hot (20)

E mail transfer .74
E mail transfer .74E mail transfer .74
E mail transfer .74
 
Simple mail transfer protocol
Simple mail transfer protocolSimple mail transfer protocol
Simple mail transfer protocol
 
Dictributed application by Waqas
Dictributed application by WaqasDictributed application by Waqas
Dictributed application by Waqas
 
Lecture 9 electronic_mail_representation_and_transfer
Lecture 9 electronic_mail_representation_and_transferLecture 9 electronic_mail_representation_and_transfer
Lecture 9 electronic_mail_representation_and_transfer
 
E-Mail - Technical Overview
E-Mail - Technical OverviewE-Mail - Technical Overview
E-Mail - Technical Overview
 
Smtp, pop3, imapv 4
Smtp, pop3, imapv 4Smtp, pop3, imapv 4
Smtp, pop3, imapv 4
 
Imap(internet massege access protocaols)
Imap(internet massege access protocaols)Imap(internet massege access protocaols)
Imap(internet massege access protocaols)
 
Unit 5 application layer
Unit 5 application layerUnit 5 application layer
Unit 5 application layer
 
Mail server
Mail serverMail server
Mail server
 
SMTP - SIMPLE MAIL TRANSFER PROTOCOL
SMTP - SIMPLE MAIL TRANSFER PROTOCOLSMTP - SIMPLE MAIL TRANSFER PROTOCOL
SMTP - SIMPLE MAIL TRANSFER PROTOCOL
 
Performance Evaluation of XMPP on the Web
Performance Evaluation of XMPP on the WebPerformance Evaluation of XMPP on the Web
Performance Evaluation of XMPP on the Web
 
transfer protocols,ftp,smtp,pop,imap
transfer protocols,ftp,smtp,pop,imaptransfer protocols,ftp,smtp,pop,imap
transfer protocols,ftp,smtp,pop,imap
 
Rpc Case Studies (Distributed computing)
Rpc Case Studies (Distributed computing)Rpc Case Studies (Distributed computing)
Rpc Case Studies (Distributed computing)
 
retrieving the mail
retrieving the mailretrieving the mail
retrieving the mail
 
E mail protocol - SMTP
E mail protocol - SMTPE mail protocol - SMTP
E mail protocol - SMTP
 
MSB-Remote procedure call
MSB-Remote procedure callMSB-Remote procedure call
MSB-Remote procedure call
 
Simple Mail Transfer Protocol
Simple Mail Transfer ProtocolSimple Mail Transfer Protocol
Simple Mail Transfer Protocol
 
Chapter 2 - Application Layer
Chapter 2 - Application LayerChapter 2 - Application Layer
Chapter 2 - Application Layer
 
Lecture application layer
Lecture application layerLecture application layer
Lecture application layer
 
file transfer and access utilities
file transfer and access utilitiesfile transfer and access utilities
file transfer and access utilities
 

Similar to Chat app case study - xmpp vs SIP

Chapter2 Application
Chapter2 ApplicationChapter2 Application
Chapter2 Application
Diego Corrales
 
Application layer
Application layerApplication layer
Application layer
Neha Kurale
 
Application layer
Application layerApplication layer
Application layer
Neha Kurale
 
Linux Inter Process Communication
Linux Inter Process CommunicationLinux Inter Process Communication
Linux Inter Process Communication
Abhishek Sagar
 
6. Chapter_2_1_newversion1.pptxasasasdasdasda
6. Chapter_2_1_newversion1.pptxasasasdasdasda6. Chapter_2_1_newversion1.pptxasasasdasdasda
6. Chapter_2_1_newversion1.pptxasasasdasdasda
UsamaMushtaq15
 
20CS2008 Computer Networks
20CS2008 Computer Networks 20CS2008 Computer Networks
20CS2008 Computer Networks
Kathirvel Ayyaswamy
 
The Art of Message Queues - TEKX
The Art of Message Queues - TEKXThe Art of Message Queues - TEKX
The Art of Message Queues - TEKX
Mike Willbanks
 
Viloria osi layer4-7
Viloria osi layer4-7Viloria osi layer4-7
Viloria osi layer4-7
Jhoniel Viloria
 
2.communcation in distributed system
2.communcation in distributed system2.communcation in distributed system
2.communcation in distributed system
Gd Goenka University
 
applicationapplicationapplicationapplication.ppt
applicationapplicationapplicationapplication.pptapplicationapplicationapplicationapplication.ppt
applicationapplicationapplicationapplication.ppt
DEEPAK948083
 
[@NaukriEngineering] Messaging Queues
[@NaukriEngineering] Messaging Queues[@NaukriEngineering] Messaging Queues
[@NaukriEngineering] Messaging Queues
Naukri.com
 
Ex 1 chapter03-appliation-layer-tony_chen
Ex 1 chapter03-appliation-layer-tony_chenEx 1 chapter03-appliation-layer-tony_chen
Ex 1 chapter03-appliation-layer-tony_chen
Đô GiẢn
 
Ex 1 chapter03-appliation-layer-tony_chen
Ex 1 chapter03-appliation-layer-tony_chenEx 1 chapter03-appliation-layer-tony_chen
Ex 1 chapter03-appliation-layer-tony_chen
Đô GiẢn
 
Intranet Messaging Project Report -phpapp02
Intranet Messaging Project Report -phpapp02Intranet Messaging Project Report -phpapp02
Intranet Messaging Project Report -phpapp02
dvicky12
 
Web services Concepts
Web services ConceptsWeb services Concepts
Web services Concepts
pasam suresh
 
Lecture-2012-2-Application Layer-Introduction.ppt
Lecture-2012-2-Application Layer-Introduction.pptLecture-2012-2-Application Layer-Introduction.ppt
Lecture-2012-2-Application Layer-Introduction.ppt
Rashmin Tanna
 
Dotnet network prog_chap07
Dotnet network prog_chap07Dotnet network prog_chap07
Dotnet network prog_chap07
Truong NGUYEN
 
XMPP and SIP Presence Protocols for Messaging and Session Control.pptx
XMPP and SIP Presence Protocols for Messaging and Session Control.pptxXMPP and SIP Presence Protocols for Messaging and Session Control.pptx
XMPP and SIP Presence Protocols for Messaging and Session Control.pptx
GSCWU
 
CHP-4.pptx
CHP-4.pptxCHP-4.pptx
CHP-4.pptx
FamiDan
 
Final networks lab manual
Final networks lab manualFinal networks lab manual
Final networks lab manual
Jaya Prasanna
 

Similar to Chat app case study - xmpp vs SIP (20)

Chapter2 Application
Chapter2 ApplicationChapter2 Application
Chapter2 Application
 
Application layer
Application layerApplication layer
Application layer
 
Application layer
Application layerApplication layer
Application layer
 
Linux Inter Process Communication
Linux Inter Process CommunicationLinux Inter Process Communication
Linux Inter Process Communication
 
6. Chapter_2_1_newversion1.pptxasasasdasdasda
6. Chapter_2_1_newversion1.pptxasasasdasdasda6. Chapter_2_1_newversion1.pptxasasasdasdasda
6. Chapter_2_1_newversion1.pptxasasasdasdasda
 
20CS2008 Computer Networks
20CS2008 Computer Networks 20CS2008 Computer Networks
20CS2008 Computer Networks
 
The Art of Message Queues - TEKX
The Art of Message Queues - TEKXThe Art of Message Queues - TEKX
The Art of Message Queues - TEKX
 
Viloria osi layer4-7
Viloria osi layer4-7Viloria osi layer4-7
Viloria osi layer4-7
 
2.communcation in distributed system
2.communcation in distributed system2.communcation in distributed system
2.communcation in distributed system
 
applicationapplicationapplicationapplication.ppt
applicationapplicationapplicationapplication.pptapplicationapplicationapplicationapplication.ppt
applicationapplicationapplicationapplication.ppt
 
[@NaukriEngineering] Messaging Queues
[@NaukriEngineering] Messaging Queues[@NaukriEngineering] Messaging Queues
[@NaukriEngineering] Messaging Queues
 
Ex 1 chapter03-appliation-layer-tony_chen
Ex 1 chapter03-appliation-layer-tony_chenEx 1 chapter03-appliation-layer-tony_chen
Ex 1 chapter03-appliation-layer-tony_chen
 
Ex 1 chapter03-appliation-layer-tony_chen
Ex 1 chapter03-appliation-layer-tony_chenEx 1 chapter03-appliation-layer-tony_chen
Ex 1 chapter03-appliation-layer-tony_chen
 
Intranet Messaging Project Report -phpapp02
Intranet Messaging Project Report -phpapp02Intranet Messaging Project Report -phpapp02
Intranet Messaging Project Report -phpapp02
 
Web services Concepts
Web services ConceptsWeb services Concepts
Web services Concepts
 
Lecture-2012-2-Application Layer-Introduction.ppt
Lecture-2012-2-Application Layer-Introduction.pptLecture-2012-2-Application Layer-Introduction.ppt
Lecture-2012-2-Application Layer-Introduction.ppt
 
Dotnet network prog_chap07
Dotnet network prog_chap07Dotnet network prog_chap07
Dotnet network prog_chap07
 
XMPP and SIP Presence Protocols for Messaging and Session Control.pptx
XMPP and SIP Presence Protocols for Messaging and Session Control.pptxXMPP and SIP Presence Protocols for Messaging and Session Control.pptx
XMPP and SIP Presence Protocols for Messaging and Session Control.pptx
 
CHP-4.pptx
CHP-4.pptxCHP-4.pptx
CHP-4.pptx
 
Final networks lab manual
Final networks lab manualFinal networks lab manual
Final networks lab manual
 

More from Genora Infotech

Startup guide
Startup guideStartup guide
Startup guide
Genora Infotech
 
Notes sharing platform
Notes sharing platformNotes sharing platform
Notes sharing platform
Genora Infotech
 
Hyperlocal food and grocery delivery platform
Hyperlocal food and grocery delivery platformHyperlocal food and grocery delivery platform
Hyperlocal food and grocery delivery platform
Genora Infotech
 
Tevendo - Sell Buy App Platform
Tevendo - Sell Buy App PlatformTevendo - Sell Buy App Platform
Tevendo - Sell Buy App Platform
Genora Infotech
 
Arabic tutor App
Arabic tutor AppArabic tutor App
Arabic tutor App
Genora Infotech
 
Events staff management app platform
Events staff management app platformEvents staff management app platform
Events staff management app platform
Genora Infotech
 
Fleet mngt erp by genora
Fleet mngt erp by genoraFleet mngt erp by genora
Fleet mngt erp by genora
Genora Infotech
 
Wellness mobile application
Wellness mobile applicationWellness mobile application
Wellness mobile application
Genora Infotech
 
Vehicle maintenance and damage reporting app
Vehicle maintenance and damage reporting app Vehicle maintenance and damage reporting app
Vehicle maintenance and damage reporting app
Genora Infotech
 
College ERP solutions
College ERP solutionsCollege ERP solutions
College ERP solutions
Genora Infotech
 
Milind prabhu
Milind prabhuMilind prabhu
Milind prabhu
Genora Infotech
 
Mobile apps technology 2018
Mobile apps technology 2018Mobile apps technology 2018
Mobile apps technology 2018
Genora Infotech
 
Genora profile Corporate profile Ver Jan 2018
Genora profile Corporate profile Ver Jan 2018Genora profile Corporate profile Ver Jan 2018
Genora profile Corporate profile Ver Jan 2018
Genora Infotech
 
Mobile App testing guidelines at genora
Mobile App testing guidelines at genoraMobile App testing guidelines at genora
Mobile App testing guidelines at genora
Genora Infotech
 
Genora Infotech - Business Presentation (Version 05.14)
Genora Infotech - Business Presentation (Version 05.14)Genora Infotech - Business Presentation (Version 05.14)
Genora Infotech - Business Presentation (Version 05.14)
Genora Infotech
 

More from Genora Infotech (15)

Startup guide
Startup guideStartup guide
Startup guide
 
Notes sharing platform
Notes sharing platformNotes sharing platform
Notes sharing platform
 
Hyperlocal food and grocery delivery platform
Hyperlocal food and grocery delivery platformHyperlocal food and grocery delivery platform
Hyperlocal food and grocery delivery platform
 
Tevendo - Sell Buy App Platform
Tevendo - Sell Buy App PlatformTevendo - Sell Buy App Platform
Tevendo - Sell Buy App Platform
 
Arabic tutor App
Arabic tutor AppArabic tutor App
Arabic tutor App
 
Events staff management app platform
Events staff management app platformEvents staff management app platform
Events staff management app platform
 
Fleet mngt erp by genora
Fleet mngt erp by genoraFleet mngt erp by genora
Fleet mngt erp by genora
 
Wellness mobile application
Wellness mobile applicationWellness mobile application
Wellness mobile application
 
Vehicle maintenance and damage reporting app
Vehicle maintenance and damage reporting app Vehicle maintenance and damage reporting app
Vehicle maintenance and damage reporting app
 
College ERP solutions
College ERP solutionsCollege ERP solutions
College ERP solutions
 
Milind prabhu
Milind prabhuMilind prabhu
Milind prabhu
 
Mobile apps technology 2018
Mobile apps technology 2018Mobile apps technology 2018
Mobile apps technology 2018
 
Genora profile Corporate profile Ver Jan 2018
Genora profile Corporate profile Ver Jan 2018Genora profile Corporate profile Ver Jan 2018
Genora profile Corporate profile Ver Jan 2018
 
Mobile App testing guidelines at genora
Mobile App testing guidelines at genoraMobile App testing guidelines at genora
Mobile App testing guidelines at genora
 
Genora Infotech - Business Presentation (Version 05.14)
Genora Infotech - Business Presentation (Version 05.14)Genora Infotech - Business Presentation (Version 05.14)
Genora Infotech - Business Presentation (Version 05.14)
 

Recently uploaded

IE-469-Lecture-Notes-3IE-469-Lecture-Notes-3.pptx
IE-469-Lecture-Notes-3IE-469-Lecture-Notes-3.pptxIE-469-Lecture-Notes-3IE-469-Lecture-Notes-3.pptx
IE-469-Lecture-Notes-3IE-469-Lecture-Notes-3.pptx
BehairyAhmed2
 
Software Engineering and Project Management - Activity Planning
Software Engineering and Project Management - Activity PlanningSoftware Engineering and Project Management - Activity Planning
Software Engineering and Project Management - Activity Planning
Prakhyath Rai
 
libro de modelado de diseño-part-1[160-250].pdf
libro de modelado de diseño-part-1[160-250].pdflibro de modelado de diseño-part-1[160-250].pdf
libro de modelado de diseño-part-1[160-250].pdf
celiosilva66
 
ARITMETICO.pdf xxxxxxxxxxxxxxxxxxxxxxxx
ARITMETICO.pdf  xxxxxxxxxxxxxxxxxxxxxxxxARITMETICO.pdf  xxxxxxxxxxxxxxxxxxxxxxxx
ARITMETICO.pdf xxxxxxxxxxxxxxxxxxxxxxxx
alemaro1123
 
Traffic Engineering-MODULE-1 vtu syllabus.pptx
Traffic Engineering-MODULE-1 vtu syllabus.pptxTraffic Engineering-MODULE-1 vtu syllabus.pptx
Traffic Engineering-MODULE-1 vtu syllabus.pptx
mailmad391
 
杨洋李一桐做爱视频流出【网芷:ht28.co】国产国产午夜精华>>>[网趾:ht28.co】]<<<
杨洋李一桐做爱视频流出【网芷:ht28.co】国产国产午夜精华>>>[网趾:ht28.co】]<<<杨洋李一桐做爱视频流出【网芷:ht28.co】国产国产午夜精华>>>[网趾:ht28.co】]<<<
杨洋李一桐做爱视频流出【网芷:ht28.co】国产国产午夜精华>>>[网趾:ht28.co】]<<<
amzhoxvzidbke
 
lecture10-efficient-scoring.ppmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmt
lecture10-efficient-scoring.ppmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmtlecture10-efficient-scoring.ppmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmt
lecture10-efficient-scoring.ppmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmt
RAtna29
 
Jet Propulsion and its working principle.pdf
Jet Propulsion and its working principle.pdfJet Propulsion and its working principle.pdf
Jet Propulsion and its working principle.pdf
KIET Group of Institutions
 
CONFINED SPACE ENTRY TRAINING FOR OIL INDUSTRY ppt
CONFINED SPACE ENTRY TRAINING FOR OIL INDUSTRY pptCONFINED SPACE ENTRY TRAINING FOR OIL INDUSTRY ppt
CONFINED SPACE ENTRY TRAINING FOR OIL INDUSTRY ppt
ASHOK KUMAR SINGH
 
Best Practices of Clothing Businesses in Talavera, Nueva Ecija, A Foundation ...
Best Practices of Clothing Businesses in Talavera, Nueva Ecija, A Foundation ...Best Practices of Clothing Businesses in Talavera, Nueva Ecija, A Foundation ...
Best Practices of Clothing Businesses in Talavera, Nueva Ecija, A Foundation ...
IJAEMSJORNAL
 
Rockets and missiles notes engineering ppt
Rockets and missiles notes engineering pptRockets and missiles notes engineering ppt
Rockets and missiles notes engineering ppt
archithaero
 
Stiffness Method for structure analysis - Truss
Stiffness Method  for structure analysis - TrussStiffness Method  for structure analysis - Truss
Stiffness Method for structure analysis - Truss
adninhaerul
 
printing of ic circuits.pdf
printing       of        ic     circuits.pdfprinting       of        ic     circuits.pdf
printing of ic circuits.pdf
chidambaramnatarajar
 
Online toll plaza booking system project report.doc.pdf
Online toll plaza booking system project report.doc.pdfOnline toll plaza booking system project report.doc.pdf
Online toll plaza booking system project report.doc.pdf
Kamal Acharya
 
Top EPC companies in India - Best EPC Contractor
Top EPC companies in India - Best EPC  ContractorTop EPC companies in India - Best EPC  Contractor
Top EPC companies in India - Best EPC Contractor
MangeshK6
 
Evento anual Splunk .conf24 Highlights recap
Evento anual Splunk .conf24 Highlights recapEvento anual Splunk .conf24 Highlights recap
Evento anual Splunk .conf24 Highlights recap
Rafael Santos
 
Red Hat Enterprise Linux Administration 9.0 RH124 pdf
Red Hat Enterprise Linux Administration 9.0 RH124 pdfRed Hat Enterprise Linux Administration 9.0 RH124 pdf
Red Hat Enterprise Linux Administration 9.0 RH124 pdf
mdfkobir
 
Quadcopter Dynamics, Stability and Control
Quadcopter Dynamics, Stability and ControlQuadcopter Dynamics, Stability and Control
Quadcopter Dynamics, Stability and Control
Blesson Easo Varghese
 
Business Development_ Identifying and Seizing Market Opportunities with Skyle...
Business Development_ Identifying and Seizing Market Opportunities with Skyle...Business Development_ Identifying and Seizing Market Opportunities with Skyle...
Business Development_ Identifying and Seizing Market Opportunities with Skyle...
Skyler Bloom
 
Girls Call Mysore 000XX00000 Provide Best And Top Girl Service And No1 in City
Girls Call Mysore 000XX00000 Provide Best And Top Girl Service And No1 in CityGirls Call Mysore 000XX00000 Provide Best And Top Girl Service And No1 in City
Girls Call Mysore 000XX00000 Provide Best And Top Girl Service And No1 in City
rawankhanlove256
 

Recently uploaded (20)

IE-469-Lecture-Notes-3IE-469-Lecture-Notes-3.pptx
IE-469-Lecture-Notes-3IE-469-Lecture-Notes-3.pptxIE-469-Lecture-Notes-3IE-469-Lecture-Notes-3.pptx
IE-469-Lecture-Notes-3IE-469-Lecture-Notes-3.pptx
 
Software Engineering and Project Management - Activity Planning
Software Engineering and Project Management - Activity PlanningSoftware Engineering and Project Management - Activity Planning
Software Engineering and Project Management - Activity Planning
 
libro de modelado de diseño-part-1[160-250].pdf
libro de modelado de diseño-part-1[160-250].pdflibro de modelado de diseño-part-1[160-250].pdf
libro de modelado de diseño-part-1[160-250].pdf
 
ARITMETICO.pdf xxxxxxxxxxxxxxxxxxxxxxxx
ARITMETICO.pdf  xxxxxxxxxxxxxxxxxxxxxxxxARITMETICO.pdf  xxxxxxxxxxxxxxxxxxxxxxxx
ARITMETICO.pdf xxxxxxxxxxxxxxxxxxxxxxxx
 
Traffic Engineering-MODULE-1 vtu syllabus.pptx
Traffic Engineering-MODULE-1 vtu syllabus.pptxTraffic Engineering-MODULE-1 vtu syllabus.pptx
Traffic Engineering-MODULE-1 vtu syllabus.pptx
 
杨洋李一桐做爱视频流出【网芷:ht28.co】国产国产午夜精华>>>[网趾:ht28.co】]<<<
杨洋李一桐做爱视频流出【网芷:ht28.co】国产国产午夜精华>>>[网趾:ht28.co】]<<<杨洋李一桐做爱视频流出【网芷:ht28.co】国产国产午夜精华>>>[网趾:ht28.co】]<<<
杨洋李一桐做爱视频流出【网芷:ht28.co】国产国产午夜精华>>>[网趾:ht28.co】]<<<
 
lecture10-efficient-scoring.ppmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmt
lecture10-efficient-scoring.ppmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmtlecture10-efficient-scoring.ppmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmt
lecture10-efficient-scoring.ppmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmt
 
Jet Propulsion and its working principle.pdf
Jet Propulsion and its working principle.pdfJet Propulsion and its working principle.pdf
Jet Propulsion and its working principle.pdf
 
CONFINED SPACE ENTRY TRAINING FOR OIL INDUSTRY ppt
CONFINED SPACE ENTRY TRAINING FOR OIL INDUSTRY pptCONFINED SPACE ENTRY TRAINING FOR OIL INDUSTRY ppt
CONFINED SPACE ENTRY TRAINING FOR OIL INDUSTRY ppt
 
Best Practices of Clothing Businesses in Talavera, Nueva Ecija, A Foundation ...
Best Practices of Clothing Businesses in Talavera, Nueva Ecija, A Foundation ...Best Practices of Clothing Businesses in Talavera, Nueva Ecija, A Foundation ...
Best Practices of Clothing Businesses in Talavera, Nueva Ecija, A Foundation ...
 
Rockets and missiles notes engineering ppt
Rockets and missiles notes engineering pptRockets and missiles notes engineering ppt
Rockets and missiles notes engineering ppt
 
Stiffness Method for structure analysis - Truss
Stiffness Method  for structure analysis - TrussStiffness Method  for structure analysis - Truss
Stiffness Method for structure analysis - Truss
 
printing of ic circuits.pdf
printing       of        ic     circuits.pdfprinting       of        ic     circuits.pdf
printing of ic circuits.pdf
 
Online toll plaza booking system project report.doc.pdf
Online toll plaza booking system project report.doc.pdfOnline toll plaza booking system project report.doc.pdf
Online toll plaza booking system project report.doc.pdf
 
Top EPC companies in India - Best EPC Contractor
Top EPC companies in India - Best EPC  ContractorTop EPC companies in India - Best EPC  Contractor
Top EPC companies in India - Best EPC Contractor
 
Evento anual Splunk .conf24 Highlights recap
Evento anual Splunk .conf24 Highlights recapEvento anual Splunk .conf24 Highlights recap
Evento anual Splunk .conf24 Highlights recap
 
Red Hat Enterprise Linux Administration 9.0 RH124 pdf
Red Hat Enterprise Linux Administration 9.0 RH124 pdfRed Hat Enterprise Linux Administration 9.0 RH124 pdf
Red Hat Enterprise Linux Administration 9.0 RH124 pdf
 
Quadcopter Dynamics, Stability and Control
Quadcopter Dynamics, Stability and ControlQuadcopter Dynamics, Stability and Control
Quadcopter Dynamics, Stability and Control
 
Business Development_ Identifying and Seizing Market Opportunities with Skyle...
Business Development_ Identifying and Seizing Market Opportunities with Skyle...Business Development_ Identifying and Seizing Market Opportunities with Skyle...
Business Development_ Identifying and Seizing Market Opportunities with Skyle...
 
Girls Call Mysore 000XX00000 Provide Best And Top Girl Service And No1 in City
Girls Call Mysore 000XX00000 Provide Best And Top Girl Service And No1 in CityGirls Call Mysore 000XX00000 Provide Best And Top Girl Service And No1 in City
Girls Call Mysore 000XX00000 Provide Best And Top Girl Service And No1 in City
 

Chat app case study - xmpp vs SIP

  • 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.