XMPP(Extensible Messaging and Presence Protocol) 소개

Project/Instant Messaging 2013. 1. 11. 10:27

Extensible Messaging and Presence Protocol (XMPP) is a communications protocol for message-oriented middleware based on XML (Extensible Markup Language).[1] The protocol was originally named Jabber,[2] and was developed by the Jabber open-source community in 1999 for near real-time, instant messaging (IM), presence information, and contact list maintenance. Designed to be extensible, the protocol has also been used for publish-subscribe systems, signalling for VoIP, video, file transfer, gaming, Internet of Things (IoT) applications such as the smart grid, and social networking services.

Unlike most instant messaging protocols, XMPP is defined in an open standard and uses an open systems approach of development and application, by which anyone may implement an XMPP service and interoperate with other organizations' implementations. Because XMPP is an open protocol, implementations can be developed using any software license; although many server, client, and library implementations are distributed as free and open-source software, numerousfreeware and commercial software implementations also exist.

The Internet Engineering Task Force (IETF) formed an XMPP working group in 2002 to formalize the core protocols as an IETF instant messaging and presence technology. The XMPP Working group produced four specifications (RFC 3920, RFC 3921, RFC 3922, RFC 3923), which were approved as Proposed Standards in 2004. In 2011, RFC 3920 and RFC 3921 were superseded by RFC 6120 and RFC 6121 respectively, with RFC 6122 specifying the XMPP address format. In addition to these core protocols standardized at the IETF, the XMPP Standards Foundation (formerly the Jabber Software Foundation) is active in developing open XMPP extensions.

XMPP-based software is deployed widely across the Internet, and by 2003, was used by over ten million people worldwide, according to the XMPP Standards Foundation.[3]

Internet protocol suite
Application layer
Transport layer
Internet layer
Link layer

History[edit]

Jeremie Miller began working on the Jabber technology in 1998 and released the first version of the jabberd server on January 4, 1999.[4] The early Jabber community focused on open-source software, mainly the jabberd server (e.g., version 1.0 in May 2000, version 1.2 in October 2000, and version 1.4 in February 2001), but its major outcome proved to be the development of the XMPP protocol.

The early Jabber protocol, as developed in 1999 and 2000, formed the basis for XMPP as published in RFC 3920 and RFC 3921 (the primary changes during formalization by the IETF's XMPP Working Group were the addition of TLS for channel encryption and SASL for authentication). Note that RFC 3920 and RFC 3921 have been superseded by RFC 6120 and RFC 6121, published in 2011.

The first IM service based on XMPP was Jabber.org, which has operated continuously since 1999 and has offered free accounts to users of XMPP.[5] From 1999 until February 2006, the service usedjabberd as its server software, at which time it migrated to ejabberd (both of which are free software application servers). In January 2010, the service migrated to the proprietary M-Link server software produced by Isode Ltd.[6]

In August 2005, Google introduced Google Talk, a combination VoIP and IM system that uses XMPP for instant messaging and as a base for a voice and file transfer signaling protocol called Jingle. (The initial launch did not include server-to-server communications; Google enabled that feature on January 17, 2006).[7] Google has since added video functionality to Google Talk, also using the Jingle protocol for signaling. In May 2013, Google announced Jabber compatibility would be dropped from Google Talk for server-to-server federation, although it would retain client-to-server support.[8]

In January 2008, AOL introduced experimental XMPP support for its AOL Instant Messenger (AIM) service,[9] allowing AIM users to communicate using the standardized, open-source XMPP. However, in March 2008, this service was discontinued.[citation needed] As of May 2011, AOL offers limited XMPP support.[10]

In September 2008, Cisco Systems acquired Jabber, Inc., the creators of the commercial product Jabber XCP.[11]

In February 2010, the social-networking site Facebook opened up its chat feature to third-party applications via XMPP.[12] The Facebook developers' site notes that Facebook Chat does not actually run an XMPP server internally, but merely presents an XMPP interface to clients; consequently, some server-side features like roster editing cannot be done via XMPP.[13]

Similarly, in December 2011, Microsoft released an XMPP interface to its Microsoft Messenger service.[14] Skype also provides limited XMPP support.[15] However, these are not native XMPP implementations.

Strengths[edit]

Decentralization
The architecture of the XMPP network is similar to email; anyone can run their own XMPP server and there is no central master server.
Open standards
The Internet Engineering Task Force has formalized XMPP as an approved instant messaging and presence technology under the name of XMPP (the latest specifications are RFC 6120 and RFC 6121). No royalties are required to implement support of these specifications and their development is not tied to a single vendor.
History
XMPP technologies have been in use since 1999. Multiple implementations of the XMPP standards exist for clients, servers, components, and code libraries.
Security
XMPP servers can be isolated from the public XMPP network (e.g., on a company intranet), and strong security (via SASL and TLS) has been built into the core XMPP specifications.
Flexibility
Custom functionality can be built on top of XMPP; to maintain interoperability, common extensions are managed by the XMPP Standards Foundation. XMPP applications beyond IM include groupchat, network management, content syndication, collaboration tools, file sharing, gaming, remote systems control and monitoring, geolocation, middleware and cloud computing, VoIP and Identity services.

Weaknesses[edit]

Does not support Quality of Service (QoS)
Assured delivery of messages has to be built on-top of the XMPP layer. Normally, this is done using simple sequence number attributes in stanzas.
Text-based communication.
Since XML is text based, normal XMPP has a higher network overhead compared to purely binary solutions. This issue is being addressed by the experimental XEP-0322: Efficient XML Interchange (EXI) Format, where XML is serialized in a very efficient binary manner, especially in schema-informed mode.
In-band binary data transfer is limited
Binary data must be first base64 encoded before it can be transmitted in-band. Therefore any significant amount of binary data (e.g., file transfers) is best transmitted out-of-band, using in-band messages to coordinate. The best example of this is the Jingle XMPP Extension Protocol, XEP-0166.

Decentralization and addressing[edit]

A simple XMPP network with the servers jabber.org and draugr.de. Green clients are online, yellow clients are writing each other and small greensubclients are the resources of one user. The brown network is not connected to the internet. The serverdraugr.de is connected to other IM services (ICQ, AIM and other) viaXMPP transports.

The XMPP network uses a client–server architecture; clients do not talk directly to one another. The model is decentralized, anyone can run a server, but neither anonymous nor peer to peer, like Skype. By design, there is no central authoritative server as there is with services such as AOL Instant Messenger or Windows Live Messenger. Some confusion often arises on this point as there is a public XMPP server being run at jabber.org, to which a large number of users subscribe. However, anyone may run their own XMPP server on their own domain.

Every user on the network has a unique Jabber ID, often abbreviated as JID. To avoid requiring a central server to maintain a list of IDs, the JID is structured like anemail address with a username and a domain name (or IP address[16]) for the server where that user resides, separated by an at sign (@), such asusername@example.com.

Since a user may wish to log in from multiple locations, they may specify a resource. A resource identifies a particular client belonging to the user (for example home, work, or mobile). This may be included in the JID by appending a slash followed by the name of the resource. For example, the full JID of a user's mobile account would be username@example.com/mobile.

Each resource may have specified a numerical value called priority. Messages simply sent to username@example.com will go to the client with highest priority, but those sent to username@example.com/mobile will go only to the mobile client. The highest priority is the one with largest numerical value.

JIDs without a username part are also valid, and may be used for system messages and control of special features on the server. A resource remains optional for these JIDs as well.

The means to route messages based on a logical endpoint identifier - the JID, instead of by an explicit IP Address present opportunities to use XMPP as an Overlay network implementation on top of different underlay networks.

XMPP as an extensible Message Oriented Middleware (xMOM) platform[edit]

XMPP provides a general framework for messaging across a network. Not surprisingly, this has a multitude of applications beyond traditional Instant Messaging (IM) and the distribution of Presence data. While several service discovery protocols exist today (such as Bonjour, or the Service Location Protocol), XMPP provides a solid base for the discovery of services (see XEP-0030 DISCO) residing locally or across a network, and the availability of these services (via Presence).

Building on its capability to support discovery across local network domains, XMPP is a perfect protocol for Cloud Computing where virtual machines, networks, and firewalls would otherwise present obstacles to alternative service discovery and presence-based solutions. Cloud computing and storage systems rely on various levels and forms of communication, including not only messaging between systems to relay state but also the migration or distribution of larger objects, such as storage or virtual machines. Along with authentication and in-transit data protection, XMPP can be applied at a variety of levels and may prove ideal as an extensible middleware or Message Oriented Middleware (MOM) protocol. Widely known for its ability to exchange XML-based content (natively), it is becoming an open platform for orchestrating the exchange of other forms of content including proprietary binary streams, Full Motion Video (FMV) content, and the transport of file-based content (see the Jingle series of extensions for numerous examples). Here the majority of the applications have nothing to do with human communications (i.e., IM) but instead provides an open means to supportMachine-to-Machine (M2M) or Peer-to Peer (P2P) communications across a diverse set of networks.

XMPP via HTTP and WebSocket transports[edit]

The original and "native" transport protocol for XMPP is Transmission Control Protocol (TCP), using open-ended XML streams over long-lived TCP connections.

As an alternative to the TCP transport, the XMPP community has also developed an HTTP transport for web clients as well as users behind restricted firewalls. In the original specification, XMPP could use HTTP in two ways: polling[17] and binding. The polling method, now deprecated, essentially implies messages stored on a server-side database are being fetched (and posted) regularly by an XMPP client by way of HTTP 'GET' and 'POST' requests. The binding method, implemented using Bidirectional-streams Over Synchronous HTTP (BOSH),[18] allows servers to push messages to clients as soon as they are sent. This push model of notification is more efficient than polling, where many of the polls return no new data.

Because the client uses HTTP, most firewalls allow clients to fetch and post messages without any hindrances. Thus, in scenarios where the TCP port used by XMPP is blocked, a server can listen on the normal HTTP port and the traffic should pass without problems. Various websites let people sign into XMPP via a browser. Furthermore, there are open public servers that listen on standard http (port 80) and https (port 443) ports, and hence allow connections from behind most firewalls. However, the IANA-registered port for BOSH is actually 5280, not 80.

A perhaps more efficient transport for real-time messaging is WebSocket, a web technology providing for bi-directional, full-duplex communications channels over a single TCP connection. Experimental implementations of XMPP over WebSocket exist, and a (now-expired) Internet-Draft documenting this approach was published at the IETF but not yet standardized.

Implementations[edit]

XMPP is implemented by a large number of clients, servers, and code libraries.[19] These implementations are provided under a variety of software licenses.

See:

Deployments[edit]

Several large public IM services natively use XMPP, including Google Talk and LiveJournal's "LJ Talk",[20] Nimbuzz, and Ovi (Nokia). Various hosting services, such as DreamHost and GMX, enable hosting customers to choose XMPP services alongside more traditional web and email services. Specialized XMPP hosting services also exist in form of cloud so that domain owners need not directly run their own XMPP servers, including Cisco WebEx Connect, Chrome.pl, Flosoft.biz, i-pobox.net, and hosted.im.

XMPP is also used in deployments of non-IM services, including smart grid systems such as demand response applications, message-oriented middleware, and as a replacement for SMS to provide text messaging on many smartphone clients.

Extensions[edit]

The XMPP Standards Foundation or XSF (formerly the Jabber Software Foundation) is active in developing open XMPP extensions. However, extensions can also be defined by any individual, software project, or organization. For example, Google has defined a number of non-XSF extensions, which are used in Google Talk and Google+ (e.g., for signalling related to Google Hangouts). Another example is the federation protocol in Apache Wave, which is based on XMPP.[21]

Competing standards[edit]

XMPP has often been regarded as a competitor to SIMPLE, based on the Session Initiation Protocol (SIP) protocol, as the standard protocol for instant messaging and presence notification.[22][23]

The XMPP extension for multi-user chat[24] can be seen as a competitor to Internet Relay Chat (IRC), although it is not as widely used as IRC.

Similarly, the XMPP extensions for publish-subscribe[25] provide many of the same features as the Advanced Message Queuing Protocol.

Connecting to other protocols[edit]

Alice sends a message through the XMPP net to the ICQ transport. The message is next routed to Bob via the ICQ network.

One of the original design goals of the early Jabber open-source community was enabling users to connect to multiple instant messaging systems (especially non-XMPP systems) through a single client application. This was done through entities called transports or gateways to other instant messaging protocols, but also to protocols such as SMS or email. Unlike multi-protocol clients, XMPP provides this access at the server level by communicating via special gateway services running alongside an XMPP server. Any user can "register" with one of these gateways by providing the information needed to log on to that network, and can then communicate with users of that network as though they were XMPP users. Thus, such gateways function as client proxies (the gateway authenticates on the user's behalf on the non-XMPP service). As a result, any client that fully supports XMPP can access any network with a gateway without extra code in the client, and without the need for the client to have direct access to the Internet. However, the client proxy model may violate terms of service on the protocol used (although such terms of service are not legally enforceable in several countries) and also requires the user to send their IM username and password to the third-party site that operates the transport (which may raise privacy and security concerns).

Another type of gateway is a server-to-server gateway, which enables a non-XMPP server deployment to connect to native XMPP servers using the built in interdomain federation features of XMPP. Such server-to-server gateways are offered by several enterprise IM software products, including:

Development[edit]

IETF[edit]

The IETF XMPP working group has produced a number of RFC protocol documents: RFC 3920 (superseded by RFC 6120), RFC 3921 (superseded by RFC 6121), RFC 3922, RFC 3923, RFC 4622, RFC 4854, RFC 4979, and RFC 6122. The most important and most widely implemented of these specifications are:

  • RFC 6120, Extensible Messaging and Presence Protocol (XMPP): Core, which describes client–server messaging using two open-ended XML streams. XML streams consist of <presence/>, <message/> and <iq/> (info/query). A connection is authenticated with Simple Authentication and Security Layer (SASL) and encrypted with Transport Layer Security (TLS).
  • RFC 6121, Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence describes instant messaging (IM), the most common application of XMPP.
  • RFC 6122, Extensible Messaging and Presence Protocol (XMPP): Address Format describes the rules for XMPP addresses, also called JabberIDs or JIDs. Currently JIDs use Stringprep (as defined inRFC 3454) for handling of Unicode characters outside the ASCII range, but this will be changed in the future to use the technology produced by the IETF's PRECIS Working Group.

XSF[edit]

The XMPP Standards Foundation (XSF) develops and publishes extensions to XMPP through a standards process centered on XMPP Extension Protocols (XEPs, previously known as Jabber Enhancement Proposals - JEPs). The following extensions are in especially wide use:

Internet of Things[edit]

XMPP features such as federation across domains, publish/subscribe, authentication and its security even for mobile endpoints are being used to implement the Internet of Things. Several XMPP extensions are part of the experimental implementation: Efficient XML Interchange (EXI) Format;[35] Sensor Data;[36] Provisioning;[37] Control;[38] Concentrators;[39] Discovery.[40]

There's a page in the XMPP wiki dedicated to Internet of Thing:.[41] You can also subscribe to the XMPP IoT mailing list:[42]

See also[edit]

References[edit]

  1. Jump up^ Johansson, Leif (April 18, 2005). "XMPP as MOM".Greater NOrdic MIddleware Symposium (GNOMIS). Oslo: University of Stockholm.
  2. Jump up^ "Jabber Inc". Cisco.com. Retrieved 2012-11-24.
  3. Jump up^ "Jabber Instant Messaging User Base Surpasses ICQ"(Press release). XMPP Standards Foundation. September 22, 2003. Retrieved November 30, 2007.
  4. Jump up^ "Open Real Time Messaging System". Tech.slashdot.org. 1999-01-04. Retrieved 2012-11-24.
  5. Jump up^ Chatting Up the Chef Linux Journal March 1, 2003 by Marcel Gagné
  6. Jump up^ "Jabber.org – XMPP Server Migration". August 12, 2009. Retrieved December 14, 2009.
  7. Jump up^ Burd, Gary (January 17, 2006). "XMPP Federation". Retrieved November 30, 2007.
  8. Jump up^ "Google's chat client drops Jabber compatibility". Heise Online. May 20, 2013. Retrieved May 27, 2013.
  9. Jump up^ Florian Jensen (2008-01-17). "AOL adopting XMPP aka Jabber". Archived from the original on 20 January 2008. Retrieved 2008-01-17.
  10. Jump up^ "AOL XMPP Gateway". 2011-05-14. Archived from the original on 22 May 2011. Retrieved 2011-05-14.
  11. Jump up^ "Cisco Announces Definitive Agreement to Acquire Jabber". Retrieved January 2, 2010.
  12. Jump up^ "Facebook Chat Now Available Everywhere". Retrieved February 11, 2010.
  13. Jump up^ "Facebook Chat API". Retrieved November 29, 2011.
  14. Jump up^ Dare Obasanjo (2011-12-14). "Anyone can build a Messenger client—with open standards access via XMPP". Windowsteamblog.com. Retrieved 2012-11-24.
  15. Jump up^ Janko Roettgers (2011-06-28). "Skype adds XMPP support, IM interoperability next? — Tech News and Analysis". Gigaom.com. Retrieved 2012-11-24.
  16. Jump up^ RFC 6122
  17. Jump up^ Joe Hildebrand, Craig Kaes, David Waite (2009-06-03)."XEP-0025: Jabber HTTP Polling". Xmpp.org. Retrieved 2012-11-24.
  18. ^ Jump up to:a b Ian Paterson, Dave Smith, Peter Saint-Andre, Jack Moffitt (2010-07-02). "XEP-0124: Bidirectional-streams Over Synchronous HTTP ([BOSH])". Xmpp.org. Retrieved 2012-11-24.
  19. Jump up^ clients, servers, and code libraries
  20. Jump up^ "Question FAQ #270-What is LJ Talk?". Livejournal.com. 2010-09-27. Retrieved 2012-11-24.
  21. Jump up^ "Google Wave Federation Protocol". Google.
  22. Jump up^ "XMPP rises to face SIMPLE standard", Infoworld magazine, April 17, 2003 XMPP rises to face SIMPLE standard
  23. Jump up^ "XMPP vs SIMPLE: The race for messaging standards", Infoworld magazine, May 23, 2003 Infoworld.com
  24. ^ Jump up to:a b XEP-0045: Multi-User Chat
  25. ^ Jump up to:a b XEP-0060: Publish-Subscribe
  26. Jump up^ "Lotus Sametime 7.5 Interoperates with AIM, Google Talk", eWeek, December 6, 2006 Eweek.com
  27. Jump up^ "Lotus ships gateway to integrate IM with AOL, Yahoo, Google", Network World, December 6, 2006Networkworld.com
  28. Jump up^ "Unified Communications: Uniting Communication Across Different Networks", Microsoft Press Release, October 1, 2009 Microsoft.com
  29. Jump up^ XEP-0004: Data Forms
  30. Jump up^ XEP-0030: Service Discovery
  31. Jump up^ XEP-0163: Personal Eventing Protocol
  32. Jump up^ XEP-0071: XHTML-IM
  33. Jump up^ XEP-0096: File Transfer
  34. Jump up^ XEP-0115: Entity Capabilities
  35. Jump up^ XEP-0322: Efficient XML
  36. Jump up^ XEP-0323: Sensor data
  37. Jump up^ XEP-0324: Provisioning
  38. Jump up^ XEP-0325: Control
  39. Jump up^ XEP-0326: Concentrators
  40. Jump up^ XEP-0347: Discovery
  41. Jump up^ XMPP IoT Wiki
  42. Jump up^ XMPP IoT mailing list

External links[edit]





source - http://en.wikipedia.org/wiki/XMPP








Extensible Messaging and Presence Protocol ( XMPP ) (이전 Jabber [1] )은 오픈 소스 의 메신저 프로토콜 및 클라이언트 서버의 총칭이다.

TCP / IP 군
응용 프로그램 계층

BGP  / DHCP  / DNS  / FTP  / HTTP  / IMAP  /IRC  / LDAP  / MGCP  / NNTP  / NTP  / POP  /RIP  / RPC  / RTP  / SIP  / SMTP  / SNMP  /SSH  / Telnet  / TFTP  / TLS / SSL  / XMPP

카테고리
전송 계층

TCP  / UDP  / DCCP  / SCTP  ​​/ RSVP  / ECN

카테고리
네트워크 계층

IP ( IPv4 , IPv6 ) / ICMP  / ICMPv6  / IGMP  /IPsec

카테고리
링크 계층

ARP / InARP  / NDP  / OSPF  / 터널링  ( L2TP ) /PPP  /MAC  ( 이더넷 , IEEE 802.11 , DSL , ISDN , FDDI )

카테고리

목차

  [ 숨기기 ] 

특징 [ 편집 ]

Jabber는 Jabber 사가 개발 한 XML 기반의 프로토콜 인 XMPP 를 사용하고있다. 다른 메이저 메신저는 사양도 프로토콜도 비공개로되어있는 것이 보통이지만, Jabber 서버 나 클라이언트도 오픈 소스이며, 그 사양은 모두 공개되어있다 ( 개방형 표준 ). 따라서 예를 들어 메일 서버 와 마찬가지로 도메인 과 서버 만 있으면 자신 만의 XMPP 서버를 구동 할 수있다. 이 점에서 다른 메신저와 다르다.

다른 인스턴트 메시징 서비스 의 게이트웨이 가되는 기능도 가진다. 이 기능을 이용하여 Jabber 클라이언트 에서 AOL Instant Messenger , MSN Messenger (. NET Messenger Service), Yahoo! 메신저 , IRC , ICQ 등의 네트워크에 메시지를 보낼 수있다. 그러나 서비스를 제공하는 서버 에서는 일본어가 통하지 않는 경우도있다.

Google Talk , Jabber를 중심으로 한 것이다.

역사 [ 편집 ]

제리미 밀러 ( 영어 ) ​​는 1998 년 에 Jabber 기술에 종사 시작, 1999 년 1 월 4 일 jabberd ( 영어 ) ​​의 첫 번째 버전을 발표했다 [2] . 초기 Jabber 커뮤니티는 오픈 소스 소프트웨어에 초점을 맞추고 있으며, 주로 jabberd 개발했다 (2000 년 5 월 버전 1.0,2000 년 10 월 버전 1.2,2001 년 2 월에 버전 1.4을 발표 )가 가장 성과는 XMPP 프로토콜을 만든 것이다.

1999 년에서 2000 년에 개발 된 초기 Jabber 프로토콜 은 XMPP 기반을 제공, XMPP는 RFC 3920 와 RFC 3921 로 공표되고있다. (IETF의 XMPP Working Group에 의한 규격화 때 주로 바뀐 부분은 전송 경로의 암호화를 위해 TLS 추가 인증을 위해 SASL 이 추가 된 곳이다.) XMPP는 잘SIMPLE ( 영어 버전 ) 경쟁 업체로 간주된다. SIMPLE은 Session Initiation Protocol (SIP) 프로토콜을 기반으로하는 인스턴트 메시징 및 현재 상태 알림 표준 프로토콜이다 [3] [4] .

XMPP를 기반으로 한 최초의 IM 서비스는 Jabber.org이며, 1999 년 이후 연속 가동하고 XMPP의 계정을 무료로 제공하고있다 [5] . 1999 년부터 2006 년 2 월까지 서비스에 jabberd를 사용했지만, 그 이후는 ejabberd ( 영어 ) ​​로 이동했다. (모두 자유 소프트웨어 의 서버 애플리케이션이다.) 2010 년 1 월에는 Isode Ltd. 에 따르면 독점 의 M-Link로 전환 할 예정이다 [6] .

2005 년 8 월에 Google 은 Google Talk 를 발표했다. 이것은 VoIP 와 IM 시스템을 아울러 가지고 인스턴트 메시징 기능에 XMPP를 사용하고, 음성 및 파일 전송 신호 프로토콜 기반 XMPP를 사용하고있다. (첫 번째 릴리스는 서버 간 통신은 포함하지 않았지만, 2006 년 1 월 17 일에이 기능이 적용되었다.) [7]

2008 년 9 월에 시스코 시스템즈 는 Jabber, Inc.와 상용 제품이다 Jabber XCP 개발자를 인수했다 [8] .

2010 년 2 월, 소셜 네트워킹 사이트의 Facebook 은 XMPP를 통해 채팅 기능을 타사 응용 프로그램에 개방했다 [9] . Facebook의 개발자 사이트는 다음과 같이주의를 당부하고있다. Facebook의 채팅은 내부에서 실제로 XMPP 서버를 가동시키고있는 것은 아니고, 단지 클라이언트에 XMPP의 인터페이스를 제공하는 것이다. 따라서 사용자 목록 편집 등 서버 사이드 기능은 XMPP를 통해 수없는 것이있다[10] .

Google Talk뿐만 아니라 많은 공공 IM 서비스가 XMPP를 사용하고, Live Journal의 LJ Talk [11] 와 Nokia의 Ovi [12] 등이 그러하다. 또한 기업의 IM 소프트웨어 제품은 네이티브에서는 XMPP를 사용 못해도 XMPP 게이트웨이를 포함하는 것이있다. 예를 들어, IBM Lotus Sametime [13] [14] 와 Microsoft Office Communications Server (OCS) [15] 등이다.

장점 [ 편집 ]

  • 중앙 서버가없는 : XMPP 네트워크 구조는 전자 메일 과 유사하며, 누구나 자신의 XMPP 서버를 세울 수 있기 때문에 중앙 서버가 존재하지 않는다.
  • 개방형 표준 : XMPP 인스턴트 메시징 서비스와 존재 기술로 XMPP라는 이름으로 IETF 에서 승인되었다. XMPP의 사양은 RFC 3920 와 RFC 3921 로 공표되고있다. 이를 구현하기 위해 로열티은 들지 않고, 특정 벤더에 얽매 수 없다.
  • 역사 : XMPP는 1998 년부터 이용되고있다. XMPP 표준 클라이언트, 서버 구성 요소 라이브러리의 구현은 많이, 썬 마이크로 시스템즈 나 Google 등의 대기업에 지원되고있다.
  • 보안 : XMPP 서버는 공공 XMPP 네트워크로부터 떼어 내도 잘 (예 : 회사의 인트라넷 등), 강력한 보안 (SASL 및 TLS를 사용)이 XMPP의 코어에 내장되어있다. 전송로의 암호화를 촉진하기 위해 2009 년 10 월 30 일까지 XMPP Standards Foundation 은 xmpp.net 중간 인증 기관 의 설치도하고, XMPP 서버 관리자에게 무료 디지털 인증서 를 제공 했다.
  • 유연성 : XMPP 이외에 사용자 지정 기능을 구현할 수있다. 상호 운용성을 유지하기 위해 일반적인 확장 XMPP Software Foundation에 의해 관리되고있다. IM 이상의 기능을 가진 XMPP 응용 프로그램으로, 네트워크 관리, 컨텐츠 전달, 그룹웨어, 파일 공유, 게임, 원격 시스템 모니터링 등이있다.

단점 [ 편집 ]

  • 현재 상태 데이터 오버 헤드 : 일반적으로 서버 간 통신의 70 %가 존재 데이터 [16] , 그 중 60 % 가까이가 중복이기 때문에 [17] 현재 XMPP는 현재 상태 데이터를 여러 수혜자에 전달하는 데 큰 오버 헤드가있다. 이 문제를 완화하는 새로운 프로토콜이 생각되고있다 [ 요청 출처 ] .
  • 대역의 바이너리 데이터의 전송은 비효율적 : XMPP는 하나의 긴 XML 문서로 인코딩되므로 이진 데이터 대역에서 전송하기 전에 먼저 Base64로 인코딩해야한다. 따라서 거대한 바이너리 데이터 (예를 들어, 파일 전송 등)은 대역 외 전송하는 것이 가장 좋고, 대역의 통신 제어를 위해 사용한다. 가장 좋은 예는 XMPP의 확장 프로토콜 인 Jingle ( 영어 ) ​​( XEP-0166 )이다.

서버의 분산 및 주소 [ 편집 ]

XMPP 네트워크는 클라이언트 서버 아키텍처를 채용하고있다 (클라이언트는 직접 통신하지)가 중앙 서버를 가지지 않는다. 권위있는 중앙 서버가 존재하지 않도록 설계되어 있으며, 이는 AOL Instant Messenger 및 Windows Live 메신저 와는 대조적이다. jabber.org에서 작동하는 공공 XMPP 서버가 존재하고, 여기에 많은 사용자가 등록되어 있기 때문에이 점 등에서 자주 혼동되지만, 누구나 자신의 도메인에서 자신의 XMPP 서버 을 세울 수있다. XMPP 표준 TCP 포트는 5222이다.

네트워크의 모든 사용자는 독특한 Jabber ID (자주 생략 JID라는)를 가진다. ID 목록의 중앙 서버를 필요하기 때문에 JID는 메일 주소 와 같은 구조를 가지고있다. 사용자 이름과 사용자가있는 서버가있는 도메인 이름 이, 앳 마크 (@)로 분할된다. 예를 들어, username@example.com과 같다.

한명의 사용자가 여러 위치에서 로그인 할 수도 있으므로, 클라이언트에서는 더 추가 문자열을 지정한다. 예를 들어, home, work, mobile 등. 이 리소스에서 사용자의 어떤 클라이언트인지를 확인한다. 그리고이 자원은 JID 뒤에 슬래시 뒤에 자원 이름을 지정하여 JID에 포함 할 수있다. 자원에는 우선 순위라는 수치를 지정해도된다. 예를 들어, 사용자의 모바일 계정의 전체 JID는 username@example.com / mobile이다. 단순히 username@example.com에 보내진 메시지는 가장 우선 순위가 높은 클라이언트에 간다, username@example.com / mobile에 보내진 것은 모바일 클라이언트 만에 간다.

메시지 전송 방법 [ 편집 ]

juliet@capulet.com 가 romeo@montague.net 에 채팅을하고 싶다고한다. Juliet와 Romeo는 각각 capulet.com하면 montague.net에 계정을 가지고있다. Juliet가 입력하여 메시지를 보내면, 일련의 이벤트가 다음과 같이 계속된다.

  1. Juliet의 클라이언트가 메시지를 capulet.com 서버에 보낸다.
    • capulet.com에서 montague.net가 차단 된 경우 메시지가 삭제된다.
  2. capulet.com 서버는 montague.net 향해 연결을 편다.
    • montague.net에서 capulet.com가 차단 된 경우 메시지가 삭제된다.
    • 이 때 Romeo가 연결되어 있지 않은 경우, 메시지는 나중에 보내기 위하여 저장된다.
  3. montague.net 서버는 Romeo에 메시지를 보낸다.
Juliet→capulet.com→montague.net→Romeo

다른 프로토콜에 연결 [ 편집 ]

Alice는 XMPP 네트워크를 통해 ICQ 전송에 메시지를 보낸다. 다음 메시지는 ICQ 네트워크를 통해 Bob에 보내진다.

XMPP의 다른 유용한 특징은 전송이다. 게이트웨이라는 이름으로도 알려져 있으며, 다른 프로토콜을 사용하는 네트워크에 액세스 할 수있게된다. 인스턴트 메시징 프로토콜뿐만 아니라, SMS 및 전자 메일등의 프로토콜도 가능하다. 멀티 프로토콜 클라이언트와 달리 원격 컴퓨터에서 동작하도록하는 특수 게이트웨이 서비스를 통해 통신하여 서버 수준에서 액세스 할 수있게하고있다. 사용자는 이러한 게이트웨이의 하나로 네트워크 로그인에 필요한 정보를 제공하고 "등록"한다. 그러면 그 사용자는 XMPP 사용자처럼 그 네트워크의 사용자와 통신 할 수있다. 즉, XMPP를 완벽하게 지원하는 클라이언트라면 게이트웨이가 존재하는 어떤 네트워크 액세스에 사용할 수 있다는 것이다. 클라이언트에 어떠한 코드를 추가 할 필요가없고, 클라이언트가 인터넷에 직접 연결할 수 필요도 없다. 이러한 기능은 사용하는 프로토콜의 이용 약관에 위반 될 가능성이 있지만, 나라마다 몇 개국인가는 그런 약관은 법적 구속력을 가지지 않는다.

관련 항목 [ 편집 ]

  • RFC 3920 - Extensible Messaging and Presence Protocol (XMPP) : Core
  • RFC 3921 - Extensible Messaging and Presence Protocol (XMPP) : Instant Messaging and Presence
  • RFC 3922 - Mapping the Extensible Messaging and Presence Protocol (XMPP) to Common Presence and Instant Messaging (CPIM)
  • RFC 3923 - End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP)

각주 [ 편집 ]

  1. ^ Jabber Inc. - About Us
  2. ^ Open Real Time Messaging System
  3. ^ "XMPP rises to face SIMPLE standard"Infoworld magazine, April 17, 2003 XMPP rises to face SIMPLE standard
  4. ^ "XMPP vs SIMPLE : The race for messaging standards"Infoworld magazine, May 23, 2003 Infoworld.com
  5. ^ Chatting Up the Chef 리눅스 필기장 March 1, 2003 by Marcel Gagné
  6. ^ " Jabber.org - XMPP Server Migration " ( 2009 년 8 월 12 일 ). 2009 년 12 월 14 일 보기.
  7. ^ Burd, Gary ( 2006 년 1 월 17 일 ). " XMPP Federation " . 2007 년 11 월 30 일 보기.
  8. ^ " Cisco Announces Definitive Agreement to Acquire Jabber " . 2010 년 1 월 2 일 보기.
  9. ^ " Facebook Chat Now Available Everywhere " . 2010 년 2 월 11 일 검색.
  10. ^ " Integrating with Facebook Chat " . 2010 년 2 월 21 일 검색.
  11. ^ Question FAQ # 270
  12. ^ Ovi Contacts
  13. ^ "Lotus Sametime 7.5 Interoperates with AIM, Google Talk", eWeek, December 6, 2006 Eweek.com
  14. ^ "Lotus ships gateway to integrate IM with AOL, Yahoo, Google", Network World, December 6, 2006 Networkworld.com
  15. ^ "Unified Communications : Uniting Communication Across Different Networks", Microsoft Press Release, October 1, 2009 Microsoft.com
  16. ^ [Standards-JIG] Distribution of stanza types
  17. ^ [Standards-JIG] proto-JEP : Smart Presence Distribution

외부 링크 [ 편집 ]


출처 - http://ja.wikipedia.org/wiki/Extensible_Messaging_and_Presence_Protocol






xmpp 개요

  • XMPP란?
RFC3920, RFC3921 등 IETF(Internet Engineering Task Force)에서 제정한 국제 표준 프로토콜로 인스턴트메신저(Instant Messenger)를 위한 프로토콜로 잘 알려져 있다. 국내에서는 몇년 전 구글(google.com)이 XMPP를 채택, googletalk 이라는 인스턴트메신저 서비스를 시작하면서 널리 알려지는 계기가 되었다. XMPP 규격은 2004년 봄에 표준으로 제정되었지만, 사실은 Jabber라는 이름으로 1998년부터 연구가 시작되었고 이 연구의 결과가 표준화라는 결과를 맞이하게 된 것이다.
  • 어떤 규격인가?
이 표준은 인터넷상의 두 지점간의 통신 규격에 관한 것이다. 두 지점은 이메일주소와 같은 방식으로 표현되며 이들 지점간 확장가능한 메시지(message) 그리고 프레즌스(presence)를 거의 실시간(near-realtime)으로 전달해주는 규격이다. 이 규격에 의하면 인터넷상의 지점은 DNS(Domain Name Service) 서비스에 의해 명명될 수 있는 위치들간의 통신으로 예를 들어 yourhost.com 이라는 주소도 하나의 지점이며yourid@yourhost.com 또한 하나의 주소이다. 결국 DNS에 의해 표현될 수 있는 주소 공간은 새로이 등록되는 도메인 이름에 의해서 계속해서 증가하므로 이론상 무한대의 사용자가 서로 통신이 가능하게 되는 규격인 셈이다.
  • 표준IM을 위한 XMPP?
알려진 대로 XMPP 프로토콜은 표준 인스턴트메신저 서비스를 위한 훌륭한 프레임워크를 제공해준다. 이미 전세계 수 많은 사람들이 XMPP 사용자가 되어 있으며 지금도 계속해서 증가하고 있다. 이것은 XMPP 소프트웨어를 만드는 회사와 단체가 증가하는 것을 보면 알 수 있다. 그러나 인스탄트 메신저 서비스만 가능한 것은 아니다. XMPP라는 규격이 Message와 동시에 Presence라는 것을 정의하고 있기 때문에 그 사용처는 매우 대단하다.
  • 강력한 Presence 기반 응용이 가능
프레즌스(Presence)는 XMPP의 가장 중요한 요소중의 하나이다. DNS에 의해 확장되는 거대한 XMPP 공간에서 각 지점의 상태들을 프레즌스라고 하고 각 지점의 상태가 변경될 경우 이 상태 변경은 즉각 이에 관심있어 하는 지점으로 브로드캐스팅된다. 다른 지점의 상태변경에 관심있는 지점이 되기 위해서는 프레즌스를 구독(subscribe)하는 과정이 필요하다.    
  • XMPP IM  
현재 AOL, MSN, Yahoo 메신저등 다양한 메신저들이 개인간 커뮤니티 도구로 널리 사용되고 있으며, 이를 기반한 다양한 차세대 킬러 어플리케이션 개발에 많은 노력을 하고 있다. 이러한 가운데 대형 포탈 또는 통신업체 등의 기업 메이저시장에서도 업체간 메신저 경쟁도 날로 치열해지고 있다. 불과 몇 년 전만 해도 메신저는 젊은 세대간의 간단한 쪽지 수준의 메시지를 전달하는 도구에 불과했었다.   그러나 지금은 메신저가 개인적인 커뮤니티뿐만 아니라 기업내의 협업을 위한 매우 유용한 도구로 활발히 이용되고 있다. 최근 메신저는 이미 수백만 명의 사용자를 가질만큼 규모가 급성장하고 있다. MSN 뿐만 아니라 AOL, Yahoo, ICQ(AOL과 통합되었음) 등 다양한 메신저들이 이미 인터넷 시장에서 ‘작은 포탈’로 주목받고 있다. 이들 메신저는 단순한 메시지 전송 기능과 파일 전송 기능을 넘어서서 교육, 증권, 은행, 음악, 복권 등 다양한 서비스를 함께 제공하고 있어 사용자들에게 인터넷만큼 편리하게 이용된다.   그러나 서로 다른 메신저를 사용하는 사용자간의 대화나 파일 전송은 불가능하다는 단점이 있다. 그 뿐만 아니라 친구 등록에는 한계가 있어서 두 개 이상의 메신저 계정을 가지고 있는 사용자는 동시에 여러 계정을 이용할 수 없다. 초기부터 많은 사업자들이 주요 서비스의 부가적인 사업정도로 인식하여 출발한 결과로 이 기종 메신저간에 커뮤니티를 전혀 고려하지 않았다. 그 결과, 서로 다른 메신저를 사용하는 사용자간에는 불편을 감수하여 여러 종류의 메신저를 설치해서 사용하거나 또는 가장 선호하는 메신저를 제외한 다른 메신저를 포기하는 경우가 대부분이다.   이러한 고객의 불편함을 해소하기 위해 마이크로소프트(MS), 야후, 아메리카온라인(AOL)등이 비즈니스용 통합 메신저 제품을 공동으로 개발하기로 합의하였다. 이를 바라보는 여러 전문가들은 비즈니스의 영역을 확보하기 위한 이 같은 행보를 꼬집어 비판하면서, 이 세 기업이 새로운 메신저 제품을 위해 얼마나 효율적으로 개발협업을 이끌어낼 지 의문을 제기하였다.   다른 한편으로는 여러 업체들이 각기 다른 메시징 소프트웨어를 제작해서 보급함에 따라 메시징 소프트웨어 간의 상호 호환성 문제에 대하여 인터넷기술표준단체 IETF(Internet Engineering Task Force)에서는 메시징 서비스 간의 호환성 문제 해결을 위한 표준 제정을 위해 XMPP(eXtensible Messaging and Presence Protocol) 워킹그룹을 결성하고 표준화를 추진하고 있다. 여기서, XMPP는 XML 스트리밍 기반 확장형 실시간 메시징 기술이다. XMPP는 공개형 프로토콜인 JABBER(http://www.jabber.org) 인스턴트 메신저에 근간을 두고 있으며 HP, SUN 등의 솔루션회사와 AT&T, Orange, France telecom, BellSouth 등의 통신회사가 채택하였다.   또한, IETF가 사람들 또는 기계간의 상태와 컨텍스트 정보를 활용하여 실시간 대화형 기술을 제시하고 있는 XMPP-core 및 XMPP-IM을 제안표준으로 채택함에 따라 XMPP 보안, XMPP-연동 등도 표준으로 채택되리라 예상되며, 향후 XMPP가 세계적 표준으로 자리 잡는데 다가섰다고 평가되고 있다.   IETF의 인스턴트 메신저 표준은 이전에 이메일이나 웹이 SMTP, HTTP로 인터넷 표준화되어 널리 사용되었듯이 향후 실시간 대화형 서비스 확산에 큰 영향을 미칠 것으로 평가되고 있다. IETF에 의해 XMPP영역의 표준으로 채택된 Jabber는 인터넷에 있는 두 지점간의 메시지, 온라인 상태정보, 및 기타 구조적(structured)정보를 실시간으로 교환하기 위한 스트리밍 XML 프로토콜 및 기술을 의미한다.   Jabber 서비스를 이용하기 위해서는 공개된 Jabber 클라이언트를 다운받고 오픈된 공개 서버에 회원가입을 하거나 직접 자신의 서버에 Jabber 대몬을 설치하고 사용할 수 있는데, 일단 가입이 이루어지면 JID라는 식별자를 부여받게 된다. JID는 이메일과 같은 체계로 되어 있다. 예를 들어 씽크테크(thinktek.co.kr)가 재버서버를 설치하고 jklee라는 사용자를 가입시켰다면 이 사용자의 JID는 jklee@thinktek.co.kr이 된다. 이는 공교롭게도 이메일 주소와 동일하다. 즉, JID는 전세계적으로 유일한 ID가 된다.   Jabber의 최대 특징은 JID만 알면 다른 어떤 Jabber 서버의 사용자와도 대화가 가능하다는 점이다. 즉, david@jabber.org 라는 JID를 가진 사용자에게 이메일을 쓰듯 메시지를 날리면 실시간 대화가 가능하다. 이 점이 다른 메신저 사업자들과 비교했을 때 가장 특징적이며 획기적인 것이다.   향후 재버서버가 메일서버만큼 널리 사용되고 많은 사용자들이 JID를 보유하게 될 때에는 Jabber를 바탕으로 하는 수 많은 응용프로그램 수요가 발생하게 될 것으로 예상된다. 사람들이 일단 JID를 이용하여 상대방과 대화를 하기 시작한다면 그 이후는 대화상태 찾기, 게임, 온라인 거래, 계약 등등 수 많은 일들을 Jabber기반의 네트워크에서 처리할 수 있게 된다.   Jabber 프로토콜은 확장성을 고려하여 초기부터 XML이라는 구조적 기술언어를 이용하여 프로토콜이 설계되어 있다. XML의 특성상 풍부한 확장성을 제공하기에 Jabber응용프로그램을 개발하는 개발자는 자신이 새로 설계한 구조적인 정보를 Jabber 네트워크를 통하여 쉽게 전송할 수 있다. 결과적으로 XML에 의해 어떠한 구조적인 정보를 정의하느냐가 Jabber 어플리케이션 개발의 핵심이 되는 것이다.  


출처 - http://www.xmpp.co.kr/?q=node/62





XMPP(Extensible Messaging and Presence Protocol) 소개


요약：  XMPP는 XML 기반 인터넷 통신을 위한 오픈 프로토콜입니다. 이 프로토콜은 인스턴트 메시징 프로토콜로 잘 알려져 있기는 하지만 일반적인 메시징 서비스로도 사용할 수 있습니다. 이 기사에서는 XMPP를 설명한 다음 XMPP를 사용하여 간단한 메시징 기능을 구현하는 방법을 살펴봅니다.

2009년 9월 18일 업데이트: 독자와 저자의 의견을 반영하여 XSF(XMPP Standards Foundation) 웹 사이트 및 XMPP Discussion에 대한 리소스가 추가되었습니다


IM(Instant messaging)은 일반적인 인터넷 사용자뿐만 아니라 비즈니스 사용자에게도 유명한 애플리케이션이다. 이 애플리케이션을 사용하면 다른 사용자와 실시간으로 통신할 수 있을 뿐 아니라 다른 사용자의 상태 정보(사용 가능, 자리 비움, 오프라인 등)도 확인할 수 있다. 초기 오픈 IM 프로토콜 중에는 Jeremie Miller에 의해 개발되어 1998년에 비표준 IM 프로토콜로 시작한 Jabber가 있다. XML을 기반으로 하는 확장 가능한 프로토콜인 Jabber는 다른 애플리케이션을 일반적인 전송 또는 MoM(message-oriented middleware)으로 빠르게 찾아낸다. 결과적으로 XMPP는 이러한 Jabber를 토대로 하여 RFC 3920, "Extensible Messaging and Presence Protocol(XMPP)"이라는 IETF 작업 그룹 프로토콜 문서 형식의 표준 기반 프로토콜이 되었다.

자주 사용하는 약어

  • API: Application programming interface
  • EVA: Extra Vehicular Activity
  • IETF: Internet Engineering Task Force
  • HTTP: Hypertext Transfer Protocol
  • RFC: Request for comments
  • RPC: Remote procedure call
  • SMTP: Simple Mail Transport Protocol
  • SOAP: Simple Object Access Protocol
  • TCP: Transmission Control Protocol
  • URL: Uniform Resource Locator
  • XML: Extensible Markup Language

범용 메시징 전송 프로토콜에는 XMPP만 있는 것이 아니다. XML-RPC 및 SOAP와 같은 다른 유명한 프로토콜에서도 함수 호출 형태의 시맨틱을 사용하여 이 기능을 제공할 수 있다. ReST(Representational State Transfer)와 같은 새로운 메소드는 URL을 사용하여 위치, 오브젝트 및 메소드를 지정할 수 있는 관리되는 파일 액세스를 제공한다.

XMPP 아키텍처

XMPP는 SMTP 등의 다른 애플리케이션 계층 프로토콜과 유사한 아키텍처를 가지고 있다. 이러한 아키텍처에서는 고유한 이름을 가지고 있는 클라이언트가 연관된 서버를 통해 고유 이름을 사용하여 다른 클라이언트와 통신한다. 각 클라이언트는 프로토콜의 클라이언트 양식을 구현하고 서버에서는 라우팅 기능을 제공한다. 그림 1에서는 이 간단한 아키텍처를 보여 준다. 이 경우에는 각 클라이언트가 같은 도메인(discovery.nasa.guv)에 속해 있다.


그림 1. 하나의 서버와 두 개의 클라이언트로 구성된 간단한 XMPP 아키텍처
하나의 서버와 두 개의 클라이언트로 구성된 간단한 XMPP 아키텍처를 보여 주는 다이어그램 

또한 서버는 도메인 간(예: discovery.nasa.guv와 europa.nasa.guv 간) 라우팅을 위해 통신할 수 있다. 그리고 게이트웨이에서는 외부 메시징 도메인 및 프로토콜 간의 변환 기능을 제공한다. 그림 2의 예제에서는 SMS(Short Message Service) 도메인과 SMTP 도메인에 대한 게이트웨이가 있는 XMPP 네트워크를 보여 준다. 게이트웨이는 이 컨텍스트에서 IM 프로토콜 간의 변환(예: XMPP를 IRC(Internet Relay Chat]로 변환)을 수행하는 데 가장 많이 사용된다. 확장 가능한 프로토콜인 XMPP는 다양한 엔드포인트 프로토콜 간의 보편적인 연결을 제공하는 이상적인 백본 프로토콜이다. XMPP 게이트웨이를 사용하면 지정된 클라이언트-투-서버 세션을 종료하고 대상 엔드포인트 프로토콜에 대한 새 세션을 시작할 수 있다(필요한 프로토콜 변환과 함께).


그림 2. XMPP 게이트웨이가 포함된 형태의 좀 더 복잡한 XMPP 아키텍처
SMS 및 SMTP 클라이언트 및 서버에 연결하는 XMPP 게이트웨이가 포함된 형태의 좀 더 복잡한 XMPP 아키텍처를 보여 주는 다이어그램 

위로

XMPP의 주소

XMPP의 주소(또는 JID[Jabber ID])는 표준 이메일 주소와 비슷하지만 몇 가지 눈에 띄는 차이가 있다. JID에는 선택적 노드, 도메인 및 선택적 리소스가 다음 형식으로 포함되어 있다.

[ node "@" ] domain [ "/" resource ]

이 주소는 이메일 주소처럼 IM 사용자를 정의할 때 가장 일반적으로 사용된다(예: DavidBowman@discovery.nasa.guv). 사용자는 XMPP 서버에 여러 번 로그인할 수 있으며, 이 경우 리소스를 사용하여 위치를 지정할 수 있다. 예를 들어, 동일한 사용자가 기본 터미널에 대한 JID(DavidBowman@discovery.nasa.guv/terminal)와 EVA pod에 대한 또 다른 JID(세션, DavidBowman@discovery.nasa.guv/eva_pod1)를 사용할 수 있다. 따라서 특정 위치를 대상으로 지정할 수 있으며 사용자가 우연히 로그인한 위치로 연결하기 위해 비워 둘 수도 있다.

위로

XMPP 프로토콜

XMPP는 XML 메시지를 사용하여 TCP 소켓 상에서 발생하는 비교적 단순한 프로토콜이다. 비동기 통신이 XML 스트림 내에서 XML 스탠자(stanza)를 통해 발생한다. XML 스트림은 두 엔터티 간에 발생하는 XML 정보 교환을 캡슐화하는 엔벨로프이다. XML 스트림은 정보의 개별 단위인 XML 스탠자를 주고 받는다. 예를 들어, XML 스탠자는 XMPP 내에서 메시지(IM 사용자 간 텍스트)와 현재 상태 정보를 주고 받는 데 사용된다. 두 클라이언트가 XMPP를 사용하여 서로 IM 통신을 수행하는 모습을 보여 주는 아래의 간단한 예제를 보면 이러한 개념을 쉽게 이해할 수 있다.

그림 3에서는 두 엔터티 간의 간단한 통신 내용을 보여 준다. 이 통신을 위해서는 적어도 하나의 서버가 있어야 한다는 점에 유의해야 한다. 이 경우에는 두 클라이언트가 모두 같은 도메인에 속해 있기 때문에 정확히 하나의 서버만 있다. 그림 3에서 왼쪽 클라이언트를 시작 엔터티(두 엔터티 간의 XMPP 통신을 시작하는 엔터티)라고 한다. 이 XML 스트림에서는 to 속성을 사용하여 수신 도메인을 식별하고 XML 네임스페이스를 정의한다. 오른쪽에 있는 수신 클라이언트는 이 XML 스트림을 수신한 후 XML 스트림 응답을 통해 응답한다(이 경우에는 from 특성 사용). 이 단계에서 인증 및 암호화와 같은 여러 다양한 협상이 수행될 수 있다. 하지만 이러한 특성과 IM 클라이언트가 별개의 도메인에 속해 있는 서버-투-서버 통신에 대해서는 이 기사에서 다루지 않는다. (그림 3의 텍스트 전용 버전 참조.)


그림 3. 샘플(단순화된) XMPP 통신 
샘플(단순화된) XMPP 통신을 보여 주는 다이어그램 

그림 3에서 설명하는 XML 스트림의 다음 단계는 메시지를 통신하는 것이다. 이 통신은 메시지 스탠자 내에서 발생하며 소스 및 대상 XMPP 주소(from 및 to), 사용 언어 및 스탠자의 본문 내에 포함된 메시지 등을 포함한다. 상대측에서는 고유 메시지를 사용하여 응답하며 주요 차이점은 소스 및 대상 XMPP 주소이다. 마지막으로 연결의 양측에서 발생하는 스트림 종료 메시지를 통해 XML 스트림이 닫힌다.

양쪽 어느 쪽에서나 아래 정의된 것과 같은 오류를 리턴할 수 있다. 이 경우에는 상대측에서 올바르지 않은 XML 스트림 또는 스탠자를 보냈다.

<stream:error>
  <xml-not-well-formed xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
<stream:error>

이 예제에서 설명한 IM 통신이 간단하기는 하지만 상대측 협상의 보안 특성에 대한 피기백을 통해 메시지 스탠자를 RPC 메시지로 쉽게 변환할 수 있다는 것을 알 수 있다. 도메인 내의 사용자 대신 함수를 노드로 등록하여 동적 웹 서비스 프레임워크를 빌드할 수 있다. 이제 XMPP 간에 통신하는 간단한 애플리케이션을 빌드하는 방법을 살펴보자.

위로

Ruby를 사용한 XMPP 예제

XMPP 라이브러리 선택하기

XMPP의 또 다른 흥미로운 특징으로는 다양한 언어를 포함한 수많은 라이브러리를 선택할 수 있다는 것이다. 이 예제에서는 Ruby 언어와 XMPP4R 라이브러리를 사용한다. 참고자료에서 지원되는 다양한 라이브러리에 대한 링크를 확인할 수 있다.

라이브러리를 통한 XMPP를 확인하기 위해 기술 사전 기능을 제공하는 간단한 IM 에이전트를 개발하는 예제를 살펴보자. 이 예제에서는 표준 인스턴트 메신저를 통해 단어를 입력하면 IM 에이전트가 해당 정의를 리턴한다.

이 예제에서는 XMPP를 통해 다른 IM 에이전트에 연결한 후 단어에 대한 정의를 확인한다. Listing 1에서는 간단한 XMPP 에이전트를 보여 준다.


Listing 1. 단어 정의를 위한 간단한 XMPP 에이전트
require 'xmpp4r/client'

# Create a *very* simple dictionary using a hash
hash = {}
hash['ruby'] = 'Greatest little object oriented scripting language'
hash['xmpp4r'] = 'Simple XMPP library for ruby'
hash['xmpp'] = 'Extensible Messaging and Presence Protocol'

# Connect to the server and authenticate
jid = Jabber::JID::new('bot@default.rs/Home')
cl = Jabber::Client::new(jid)
cl.connect
cl.auth('password')

# Indicate our presence to the server
cl.send Jabber::Presence::new

# Send a salutation to a given user that we're ready
salutation = Jabber::Message::new( 'hal@default.rs', 'DictBot ready' )
salutation.set_type(:chat).set_id('1')
cl.send salutation 

# Add a message callback to respond to peer requests
cl.add_message_callback do |inmsg|

    # Lookup the word in the dictionary
    resp = hash[inmsg.body]
    if resp == nil
      resp = "don't know about " + inmsg.body
    end

    # Send the response
    outmsg = Jabber::Message::new( inmsg.from, resp )
    outmsg.set_type(:chat).set_id('1')
    cl.send outmsg

end

# Run
while 1
end

Listing 1에서는 먼저 간단한 사전을 작성한다. 이를 위해 Ruby의 hash 클래스를 사용하게 된다. 이 클래스를 사용하면 키-값 쌍(배열로 표시됨)을 작성할 수 있으며, 작성 후에는 키를 사용하여 키-값 쌍을 쉽게 참조할 수 있다. 그런 다음 XMPP4R 라이브러리를 사용하여 서버에 연결하게 되는데 이를 위해 먼저 JID를 작성한 후 Client 클래스를 사용하여 새 클라이언트 연결을 작성한다. IM 서버에 실제로 연결하기 위해 connect메소드를 사용한다. 연결이 설정된 후에는 auth 메소드를 암호와 함께 호출한다. 이제 메시징을 위한 연결이 준비되었다.

다음 단계는 선택적인 단계로 IM 서버에 사용자의 현재 상태를 알리는 것이다. 이를 수행하기 위해 사용자의 현재 상태 스탠자를 서버에 보낸다. 그리고 사용 가능한 상태임을 알리는 선택적 메시지를 상대측에 보낸다. 이를 수행하기 위해 메시지 스탠자를 작성한 후 상대측 주소와 메시지를 사용하여 메시지 스탠자를 초기화한다. 메시지를 초기화한 후에는 Client 클래스 인스턴스와 send 메소드를 사용하여 메시지를 보낸다.

수신된 메시지를 처리하기 위해 클라이언트 연결의 add_message_callback 메소드를 사용한다. 메시지가 수신될 때마다 해당 코드 블록이 호출되면서 메시지를 처리한다. 수신 메시지는 inmsg(Message 인스턴스)로 표현된다. 먼저 수신 메시지의 body에 정의된 단어가 사전에 있는 단어인지 확인한다. nil이 리턴된 경우에는 단어가 없는 것이므로 기본 응답을 제공한다. 수신 메시지의 소스(inmsg.from)와 응답 문자열을 사용하여 새 메시지를 생성한다. 초기화가 완료되면 클라이언트 인스턴스를 통해 새 메시지를 요청자에게 보낸다.

그림 4에서는 애플리케이션의 샘플 실행을 보여 준다. 이 예제에서는 유명한 유니버설 채팅 클라이언트를 사용한다. pidgin 클라이언트는 주요 채팅 프로토콜을 모두 지원하며 여러 채팅 네트워크와 함께(심지어는 동시에) 사용할 수 있다. 그림 4에서는 IM 에이전트가 서버에 연결되어 정의된 사용자와 대화를 시작할 때 작성된 메시징 팝업 창을 보여 준다.


그림 4. 샘플 IM 세션 및 IM 에이전트
샘플 IM 세션 및 IM 에이전트를 보여 주는 화면 캡처 

이 애플리케이션은 매우 단순하지만 XMPP4R에는 계정 등록, 검색, 파일 전송, 다중 사용자 채팅, 게시/가입, RPC 등의 다양한 기능을 지원하는 여러 가지 클래스와 메소드가 있다. 참고자료에서 모든 XMPP4R 파일, 클래스 및 메소드를 쉽게 볼 수 있는 방법을 제공하는 "탐색 가능한" 클래스 API를 찾을 수 있다.

위로

XMPP의 응용 분야

XMPP는 네트워크를 통한 메시징을 위한 일반적인 프레임워크를 제공한다. 물론 이 프레임워크는 기존 IM 및 현재 상태 데이터 배포 이외의 다른 여러 분야에서도 활용할 수 있다.

IM과 비슷한 응용 분야로는 그룹 또는 다자간 메시징이나 다중 사용자 대화방 개발이 있다. 다자간 통신을 사용하면 Twitter에서 제공하는 마이크로 블로그와 비슷한 기능을 구현할 수 있다. 하지만 XMPP를 통해서는 텍스트를 포함한 다양한 유형의 데이터를 전송할 수 있으며 오디오, 이미지 및 비디오 데이터를 포함한 다양한 형식의 통신이 가능하다.

Bonjour, Service Location Protocol 등과 같은 여러 가지 서비스 검색 프로토콜이 있기는 하지만 XMPP는 네트워크에서 서비스를 검색하는 기능과 서비스 및 기능에 대한 알림 기능을 제공할 수 있는 견고한 토대를 제공한다.

온라인 게임에서도 XMPP를 활용할 수 있다. XMPP는 기본적으로 인증, 현재 상태 정보, 채팅 및 게임 상태 정보에 대한 확장 가능한 실시간 통신을 비롯하여 온라인 게임에 필수적으로 필요한 여러 가지 기능을 제공한다.

마지막으로 XMPP는 클라우드 컴퓨팅의 새 시대를 위한 완벽한 프로토콜이다. 클라우드 컴퓨팅 및 스토리지 시스템에서는 시스템 간에 메시지를 교환하여 상태 정보를 전달하는 작업부터 스토리지 또는 가상 시스템과 같은 대형 오브젝트의 마이그레이션하는 작업까지 다양한 레벨 및 다양한 형식의 통신이 수행된다. 또한 인증 및 전송 데이터 보호 분야에서도 XMPP를 다양한 레벨에서 적용할 수 있으며 특히 미들웨어 프로토콜로 사용하는 것이 이상적이다.

여기서 주목할 점은 대부분의 응용 분야가 사용자 통신과는 관련이 없고 대신 시스템 통신(MMI 또는 시스템 간 통신)과 관련된다는 것이다. 바로 이러한 특징으로 인해 IM용 프로토콜이 다양한 분야에서 사용될 수 있는 것이다.

위로

다중 언어 XMPP

XMPP는 XMPP 기능을 애플리케이션에 제공하는 라이브러리 세트로 구현된다. XMPP에서 현재 지원되는 다양한 언어를 보면 XMPP가 얼마나 유용한 프로토콜인지 쉽게 알 수 있다. C, C++ 등의 일반적인 언어를 위한 XMPP 라이브러리 소프트웨어뿐만 아니라 Ruby, Java™ 언어, Python, Perl, Tcl 등의 유명한 스크립트 언어를 위한 XMPP 라이브러리를 찾을 수 있다. 또한 Erlang, C# 및 Lisp와 같은 언어를 지원하는 XMPP 라이브러리도 제공된다. 따라서 어느 환경에서 작업하더라도 현재의 환경에서 사용할 수 있는 XMPP 라이브러리를 통해 XMPP 액세스를 얻을 수 있다. 참고자료에서 다양한 XMPP 라이브러리에서 지원되는 언어 목록을 볼 수 있다.

위로

추가 주제

ReST의 성장

ReST는 구현보다는 아키텍처 모델에 가깝지만 많은 분야에서 빠르게 성장하고 있다. 단순한 형태의 원격 리소스 관리 모델을 제공하는 ReST는 클라우드 스토리지에서 스토리지 액세스 및 관리를 위한 모델로 사용되면서 탄탄한 입지를 굳히고 있다.

많은 유용한 기술은 창시자가 생각하지도 못했던 방식으로 응용되기도 한다. 예를 들어, HTTP는 인터넷을 통해 웹 페이지를 서비스하는 사실 상의 표준 프로토콜이지만 SOAP, XML-RPC(ReST 등의 프로토콜 모델 포함) 등의 다른 프로토콜을 위한 애플리케이션 계층 전송으로도 사용된다. XMPP는 단순히 IM에 그치지 않고 많은 새 응용 분야를 찾고 있는 또 하나의 유용한 기술이다. 자 이제 XMPP를 자신의 솔루션에 활용하는 방법을 찾아보기를 바란다.


참고자료

교육

  • XMPP(Wikipedia): XMPP 및 해당 표준에 대한 유용한 소개 정보를 볼 수 있으며 XMPP와 관련된 다양한 표준과 기타 XMPP 관련 정보에 대한 링크 목록을 제공한다. 

  • XSF 웹 사이트: XMPP 서버, 클라이언트 및 라이브러리에 대한 유용한 정보를 확인하고 사용자, 관리자 및 개발자에 대한 메일링 목록을 통해 XMPP 및 개발에 참여할 수 있다. 

  • XMPP core specification: XMPP의 전체 정의를 볼 수 있다. 

  • SOAP: 구조화된(read XML) 정보의 교환을 위한 프로토콜 스펙인 SOAP에 대해 알아보자. SOAP는 HTTP를 전송으로 사용하며 인터넷을 통한 RPC에 필요한 일반적인 서비스를 제공한다. 

  • XML-RPC: XML-RPC 스펙과 분산 컴퓨팅 환경에서의 다양한 RPC 구현에 대해 설명한다. SOAP와 마찬가지로 HTTP를 전송으로 사용하며 다양한 언어 및 환경을 지원한다. 

  • ReST: HTTP 분산 오브젝트 관리를 사용하는 ReST 통신 스타일에 대해 알아보자. ReST는 HTTP의 URL 메커니즘을 사용하여 오브젝트 위치, 리소스 및 작업(명사 및 동사)을 정의한다. Wikipedia에서 ReST에 대한 좋은 소개 글과 RPC 등의 다른 기술과 비교해 놓은 기사를 볼 수 있다. 

  • XMPP: The Definitive Guide(Peter Saint-Andre, Kevin Smith 및 Remko Tronçon, O'Reilly, 2009년): Kathryn Barrett이 발췌해서 소개한 XMPP의 응용 분야 목록을 살펴보자. 이 기사에서는 XMPP를 활용한 다양한 서비스와 응용 분야에 대해 설명한다. 

  • IBM XML 인증: XML 및 관련 기술에 대한 IBM 인증 개발자가 되는 방법을 찾아볼 수 있다. 

  • XML Technical library: developerWorks XML 영역에서 다양한 기술 관련 기사와 팁, 튜토리얼, 표준 및 IBM Redbook을 볼 수 있다. 

  • developerWorks 기술 행사 및 웹 캐스트: 이들 세션에 참가하여 최신 기술에 대한 정보를 얻을 수 있다. 

  • 기술 서점: 다양한 기술 주제와 관련된 서적을 살펴볼 수 있다. 

  • developerWorks 팟캐스트: 소프트웨어 개발자의 흥미로운 인터뷰와 토론을 확인할 수 있다. 

제품 및 기술 얻기

  • XMPP libraries: 수많은 언어를 지원하는 다양한 XMPP 라이브러리를 살펴보자. 일반적으로 각 언어 환경마다 여러 라이브러리가 지원된다. Wikipedia에는 15가지 언어에 대한 XMPP 라이브러리 소프트웨어 목록이 실려 있다. 

  • XMPP4R library: XMPP 통합을 위한 클래스 세트가 필요한 경우에는 이 기사에서 사용한 XMPP4R 라이브러리가 제격이다. 다른 라이브러리도 많이 있지만 Ruby 프로그래밍에 익숙하다면 XMPP4R를 사용하는 것이 좋다. 

  • IBM 시험판 제품을 다운로드하거나 IBM SOA Sandbox의 온라인 시험판을 살펴보고 DB2®, Lotus®, Rational®, Tivoli® 및 WebSphere®의 애플리케이션 개발 도구 및 미들웨어 제품을 사용해 볼 수 있다. 

토론

필자소개

M. TIm Jones

M. Tim Jones는 임베디드 펌웨어 아키텍트이자 Artificial Intelligence: A Systems Approach, GNU/Linux Application Programming(현재 2판), AI Application Programming(현재 2판) 및 BSD Sockets Programming from a Multilanguage Perspective의 저자이다. 정지 위성을 위한 커널 개발에서 시작해 임베디드 시스템 아키텍처와 네트워크 프로토콜 개발에 이르기까지 다양한 분야에 대한 공학 지식을 가지고 있다. 콜로라도주 롱몬트 소재의 Emulex Corp.에서 선임 아키텍트로 활약하고 있다.


출처 - http://www.ibm.com/developerworks/kr/library/x-xmppintro/index.html





저작자표시

'Project > Instant Messaging' 카테고리의 다른 글

xmpp rfcs  (0) 2013.01.14
tigase information  (0) 2013.01.12
tigase 소개  (0) 2013.01.11
XMPP 아키텍쳐  (0) 2013.01.11
Simple (or Streaming) Text Oriented Message Protocol (STOMP)  (0) 2013.01.11
Posted by linuxism
,

티스토리툴바