2019-DSE-Web-Instant Messaging/extensible messaging and presence protocol

1. Instant Messaging

　　- Instant messaging is a potential near-real-time communication based on the exchange of message between two or more instances that have been registered to an Instant Messaging Service.

　　- In constrast to regular chat systems, IM has a higher degree of personailsation.

　　- IM Service works hand in hand with a Presence Service which is a means for storing, finding and distributing Presence information of participanting instances

　　- Presence Information may be shown to a user in form of a contact list by an IM client.

一个IM 客户端包含两个部分，一个是IM服务，一个就是presence server，用来存储，查找，分布呈现。不同于传统的通信系统，IM有高度的个人服务机制。

　　- The Instant Messaging Service interacts with:

　　　　- senders which send Instant Messages to a particular Instant Inbox Address by using the service for message delivery

　　　　- Instant Inboxes which are associated with an Instant Inbox Address and accept and potentially temporary store Instant Messages from the Service

　　　　- Instant Messages are distributed by an Instant Message Protocol

2. Presence Service

　　- Presentities which distribute Presence Information of an entity to the Presence Service.

　　- wathchers which receive presence information from the presence Service- two types exist:1. Fetchers explicitly request information in arbitrary or periodic intervals; 2. subscribers request automatic notification from presence service of future changes in some presentity;s presence information.

　　- presence information is distributed by the presence protocol.

persentity 从entity 区分出 presence information 通过 persence protocol 到 presence service. 与此同时，wathcers接受presence service information 从presence service。其中watcher有两种types：fetcher要求随机接受信息或者循环接受，subsribers 要求自动获得通知从presence service 里面关于presence information的任一变动。

3. does not make any assumption about the location of the components ,thus, rendering various implementation variant possible.

1. on user's initiation client a establishes a transport layer connection to the IM server

2.presentity transmits the clinet's Presence Information to the IM server ; within this step the IM server might check if there are new messages in the associated IM inbox and potentially deliver them

3. Initial fetcher requests presence information about relevant other instances

4. User A adds user B to contact list resulting in registration of the Subscriber of client A to the Presence Service for status updates of Client B

5.Client B connects to the server, informs the presence service that it is online now and receives status information about relevant contacts

6. subscriber of client A is informed about the status update of Client B

7. Client A sends a message to the Instant Inbox Address of Client B

8.The Instant message service make use of the presence service to look up if client B is online at the moment and if this is the case it determines the client's current network address

9.because client B is online the message is not sorted on the server but directly forwarded to client B that presents the message to user B

- XMPP

　　1. The extensible messaging and presence protocol is an open XML protocol for near-real-time messaging, presence and request-response services that can be used especially for IM systems

　　2. main goal:

　　　　- decentralisation

　　　　- interoperability with further IM protocol

　　　　- simple client implementations

　　　　- security

　　　　- extensiblity

　　3. instant inbox address is called Jabber Identifier(JID)

　　　　JID = [user "@"] domain["/"reource]

　　4. After registration to a XMPP server, a JID is assigned to a user that has the form user@server.com

　　5. when a client connects to a server it binds a resource identifier to itself that has the form user@server.com

　　6. by this concept it is possible to be available via different user client devices though only having one user account.

　　7. Architecture of system using XMPP for communication are heavily server centric

　　　　8. xmpp is based on two fundamental communication concepts:

　　　　　　- xml streams: container for exchange of XML elements between two instances

　　　　　　- xml stanzes: xml elements with special semantics that exist at the child level of streams

　　　　9. XML Streams

　　　　　　- The communication via XMPP can be compared to the exchange of two XML documents between client and server- one for each direction

　　　　　　- After establishing a TCP connection and initial steps for authentication and encryption, a stream is opened that functions as envelope during complete communication and , thus, is closed when the client disconnects

　　　　10.XML stanzas

　　　　　　- There exist three types of XML Stanzas that provide the building blocks for communication in an IM system:

　　　　　　　　1. message-encapsulates chat data

　　　　　　　　　　<body> Hi Vincent!</body>

　　　　　　　　　　</message>

　　　　　　　　2.presence- changes presence information and manages subscription to presence information: do not disturb---

　　　　　　　　　　</presence>

　　　　　　　　　　request for subscription

　　　　　　　　3. iq -requests or sets different information(e.g. requests the user's contact list(roster) from the server )

　　　　　　　　　　</iq>

　　　　　　　　　　- beside type "get" there exist types "set", "result" and "error"

　　　　　　　　　　- communication with the iq element is done in a request-reply-manner

　　　　11. XMPP messaging - details

　　　　　　- messages are not confirmed by receiver("fire" and "forget" semantics)

　　　　　　- several message types (attribute "type") available:

　　　　　　　　- normal(usual messages), chat(messages within an IM session), groupchat(messages within chat rooms), headline(warnings and notifications), error(error messages)

　　　　12. Message delivery between servers (federated)

　　　　　　- XMPP server assocaited to a domain may be determined via DNS using SRV resource records

　　　　　　- Server negotiates a XMPP stream with the remote server and routes received stanzas for this server via the established stream.

　　　　13. Message delivery between servers(federated)

　　　　　　- XMPP server associated to a domain may be determined via DNS using SRV resource records 　　

　　　　　　- Server negotiates a XMPP stream with the remote server and routes received stanzas for this server via the established stream

　　　　　　- XMPP connection(Communication details) 　

　　　　　　　　1. Establishing a TCP connection　　

　　　　　　　　2. Open a XML Stream from client to server

　　　　　　　　3. Open a XML Stream from server to client

　　　　　　　　4. Authentication of instances and optionally start encryption

　　　　　　　　5. Establishing of a new authenticated and potential encrypted stream for each direction

　　　　　　　　6. Register a resource at the server, thus, making it available through an address of the scheme node@domain.com/resource

　　　　　　　　7. Establishing a session on the server to finally activate instant messaging and presence functionality

　　　　　　　　8. Client requests roster items that are delivered by the server

　　　　　　　　9. Exchange of further XML Stanzas(e.g. messages that were stored by the server while the user has been offline)

　　　　　　　　10. Close XML Stream

　　　　　　- XMPP connection -details

　　　　　　　　! registration of a resource

　　　　　　　　client --- <iq type="set" id ="bind1">---->server

　　　　　　　　　　　　　</bind>

　　　　　　　　　　　　　</iq>

　　　　　　　　client <---<iq id ="bind1" type="result">----server

　　　　　　　　　　　　　</bind>

　　　　　　　　　　　　　</iq>

　　　　　　　　!!establishing a session

　　　　　　　　client -----<iq type="set" id="session1">----->servers

　　　　　　　　!!!delivery of roster items

　　　　　　　　client ----<iq from="bob@b.de/pc" type="get" id="roster1">--->servers

　　　　　　　　　　　　　　</iq>

　　　　　　　　client<---<iq to="bob@n.de/pc" type="result" id="roster1">-----servers

　　　　　　　　　　　　<group> Friends</group>

　　　　　　　　　　　　</item>

　　　　　　　　　　　　</item>

　　　　　　　　　　　　</query>

　　　　　　　　　　　　</iq>

　　　　- XMP subscription management

　　　　　　1. XMPP can make the observed presentity's confirmation of subscription necessary

　　　　　　2.During the subscription process all connected resources of involved users are informed about the progress

　　　　　　1. After Jules added Vincent to his contact list by giving his JID and a name that is presented in the user interface the roster data is updated by an iq-set operation

　　　　　　2. initiating client receives confirmation of a roster update and all connected resources are informed about this new roster item

　　　　　　3. User client sends a presence-stanza(type 'subscribe', addressed to Vincent's JID)

　　　　　　4. Server 1 informs connected resources of jules@abc.com about pending subscription state (which may be visualised by the user clients)

　　　　　　5. The presence-stanza is routed to the new contact's accountable server which forwards it to the available resource

　　　　　　6. After Vincent has confirmed the subscription, the user client updates its roster information by sending an iq-stanza followed by a presence- stanza(type 'subscribed' and attribute 'to' has value 'jules@abc.com') to confirm subscription

　　　　　　7. After pushing a roster update to all connected resources of vincent@example.com Server2 confirms the update to the sending resource

　　　　　　8. Server 2 forwards the presence-stanza of type 'subscripted' to Server 1 and sends presence information of all connected resources of vincent@xyz.com to the address jules@abc.com

　　　　　　9. The subscription confirmation is forwarded to the user client

　　　　　　10. Connected resources of Jules are informed by a pushed iq-set operation about the new subscription state and receive the presence information of all connected resources of vincent@xyz.com

　　- Disrtibution of presence information

　　　　- Server receives presence information from all connected devices and distributes this information

　　- Presdence Probe

　　　　- on behalf of its clients, a server may request presence information about client connected to other servers

　　　- Alternative connection approaches

　　　　1. Besides the basic Client-Server and Server-to-Server communication, several alternative approaches exist, such as:

　　　　　　- Jabber component protocol e.g. for accessing services via XMPP

　　　　　　- Serverless messaging for direct XMPP client interaction

　　　　　　- XMPP communication via HTTP or WebSockets

　　　- BOSH: XMPP via HTTP

　　　　1. Problem:

　　　　　　- continuous TCP connection maybe inappropriate in several use cases, e.g.:

　　　　　　　　- mobile networks: connection interruptions lead to XMPP reconnects

　　　　　　- mobile devices:

　　　　　　　　- connection interruptions occur in case an application is suspend in order to save power

　　　　　　- restrictive firewall configuration

　　　　2. Solution:

　　　　　　- HTTP long-polling:

　　　　　　　　- BOSH: bidirectional streams over synchronous HTTP

　　　　3. Connection Establishment

　　　　　　POST /webclient HTTP/1.1

　　　　　　Host: bosh.a.de

　　　　　　HTTP/1.1 200 OK

　　　　　　<stream:features>..</stream:features>

　　　　　　</body>

　　- Instant Messager

　　　　1. In order to communicate to instances that are available in different IM networks there exist two possiblities:

　　　　　　- multiple protocol client: The user client manages different accounts for each IM network, thus, supporting more than one protocol

　　　　　　- Protocol translation: IM network deploys gateways for translation between protocols; XMPP transports is one practically used gateway mechanism

发表于 2019-06-27 02:27 heathjaymzy 阅读(156) 评论(0) 收藏举报

3. does not make any assumption about the location of the components ,thus, rendering various implementation variant possible.

公告