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 â&#x20AC;&#x201C; 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 XML-based client-server protocol to similar to HTTP, where core attributes are create a streaming pipe on which it sends signaled using headers, and additional data request, response, indication or error using message body, e.g., session descriptionusing XML stanza between client and of capabilities. server, and between servers.
Transport
Usually implemented in connection-less UDP as well as connection-oriented TCP Works over connection-oriented TCP or transport. Also works over secure TLS TLS transport. transport.
A user-agent is both client and server, hence The client initiates the connection to the can send or receive connections, in case of server, which works well with NATs and TCP or TLS. This does not work well with firewalls. Additionally, extensions are Connection NATs and firewalls, hence extensions are defined such as BOSH to carry XMPP defined to use reverse connections when stanza over HTTP to work with very server wants to send message to client. 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â&#x20AC;&#x2039; ? * 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 G oogle 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â&#x20AC;&#x2039; 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â&#x20AC;&#x2039; rver CPU use for the same period of the test.