Jabber/XMPP file transmission

1 Some situations of Jabber/XMPP file transmission

As you know, Jabber/XMPP is an XML stream technology that solves the problem of instant messages and attendance information. XML stream technology is not suitable for transmission of large data volumes.
In instant messaging applications, messages and attendance information are relatively simple and easy to implement. XMPP has two advantages:
-With the XML stream technology, XML is naturally structured and scalable, and is very suitable for character information exchange with small data volumes.
-More importantly, XMPP is a public and free standard that allows instant messaging between different organizations to facilitate the transition of IM Technologies and applications from monopoly to popularization.
----- But real-time communication is also inseparable from the transmission of large data volumes to solve problems such as file sharing and multimedia applications. To solve these problems, xeps provides some solutions. Before that, we need to identify what is a large amount of data transmission. In XMPP \/xep, information transmission is called character transmission, while data transmission is bytestreams ).

The rules for bytestreams in xep are roughly as follows:
* XEP-0096: file transfer, which is the unified interface for transferring files, is used between clients to negotiate the specific transmission mode, including the following three.
* XEP-0047: in-band bytestreams with byte stream, this protocol is actually used for small data transfer, but it uses byte stream transmission, so also by the way. In-band, that is, it is carried in the XML Stream and transmitted through the XMPP server. The specific usage is to put the data in the XML Stream in base64 encoding and pass it to the other party. This method is not good, base64 encoding is very inefficient, and all data must be transferred by the server.
* XEP-0066: out of band data with out-of-band throttling, out-of-band without passing through XMPP server. This method is to temporarily create an HTTP service (or another service, of course) on the client that initiates the transmission, and notify the receiver of its own IP address and port (via XMPP message, let the recipient download it directly. This method has a problem. The sender must be a public IP address; otherwise, the sender cannot access the client. Note: currently, Pandion and LINQ support this xep.
* XEP-0065: SOCKS5 bytestreams SOCKS5 byte stream, uses SOCKS5 to transfer files, there are two methods of direct connection and proxy transmission. The sender informs the receiver of the predefined IP address and port (via XMPP message. If both parties are on the public network, Socks is used for direct transmission. If either party is transmitted through the SOCKS5 Proxy server over the Intranet, the sender will send the IP address and port of the proxy server to the receiver. The SOCKS5 Proxy Server is slightly different from the general proxy server, because it requires the XMPP server to notify the SOCKS5 Proxy Server to connect socks channels between the two parties through a sessionid proposed by the sender. Note: currently, PSI and LINQ support this xep.

----- After Google's Gtalk announced the adoption of the XMPP Standard, it adopted a new method for transmission of large data volumes, that is, jingle. In addition to file transmission, this protocol takes multimedia applications into account. However, in general, its approach is slightly different from the aforementioned method, or the aforementioned xep extension and optimization. Currently, jingle is still in the experimental state in xep, but jingle has been used in Gtalk, and Gtalk does not support the aforementioned xeps.
This is the case for the big crocodile, standing up on his own .......

But let's talk about this jingle, because Google makes jingle public after all, which is better than some commercial IM service providers. At least we have the opportunity to be compatible with it.
-XEP-0166: the protocol of jingle focuses on multimedia applications, of course, including file transmission, it puts forward the management of some multimedia applications, for example, suggestions on the separation of byte data and description data and interface management for multi-application and multi-session interfaces are also described in the jingle supplemental Protocol for different types of applications, as shown in the following table:

Protocol	Description
XEP-0166: jingle	Negotiates and manages all out-of-band transmission sessions
XEP-0167: Jingle audio via RTP	Transmit audio using RTP
XEP-0176: Jingle ice transport.	Use ICE transmission to establish and manage data connections
XEP-0177: Jingle raw UDP Transport	Pure UDP Transmission
XEP-0180: Jingle video via RTP	Transmit video with RTP
XEP-0181: Jingle DTMF	Simple Support for DTMF

Note 1: the protocol that is being developed by ice or IETF is not finalized yet.
NOTE 2: DTMF is the phone number for dual-audio dialing. The support for DTMF is defined only from the XMPP perspective and can manage DTMF sessions, in this way, you can use voice chat between the XMPP client and the phone.

These are application layer things, which have little to do with the topic here. Now we only talk about the processing process of the actual byte transmission. Jingle's own transmission is divided into three types:
* The sender transmits data over the Internet in a way similar to OOB (XEP-0066: out of band data.
* The sender transmits the data over the intranet using the stun service, that is, the port of the Intranet client. The intranet IP address and port are mapped to the stun IP address and specific port, then the Internet IP address and port to tell the other party, and then the use of OOB (XEP-0066: out of band data) transmission.
* The sender is on the Intranet, but there is no available stun server, using the relay server for forwarding, which is similar to the proxy65 (XEP-0065: SOCKS5 bytestreams) transmission method.

 

 

 

Gtalk can add the running parameter/log verbose tstamp thread file to generate a detailed log file on the desktop. The following is the XML

<Presence to = 'xxx' from = 'yyy'> <status/> <priority> 0 </Priority>
<C xmlns = "http://jabber.org/protocol/caps" node = "http://www.google.com/xmpp/client/caps" ver = "1.0.0.96" ext = "share-v1 sidebar voice-v1"/>
<C xmlns = 'HTTP: // jabber.org/protocol/caps' ext = 'share-V1 voice-v1 'ver = '1. 0.0.96' node = 'HTTP: // www.google.com/xmpp/client/caps'/>
<X xmlns = 'jabber: X: delay' stamp = '20060817t11: 43: 04 '/> <X xmlns = 'vcard-Temp: X: update'/> </presence>

Gtalk client allows file transfer only when it finds that the other party has a share-v1. It does not seem to be related to the version.

If you init a file transfer they send:

<IQ from = 'timyang 'Id = '29' type = 'set' to = 'freetmp'>
<Session xmlns = 'HTTP: // www.google.com/session' initiator = 'xxx'
Id = '000000' type = 'initiate'>
<Description xmlns = 'HTTP: // www.google.com/session/done'>
<Manifest>
<File size = '000000'>
<Name> export.csv </Name>
</File>
</Manifest>
<Protocol>
<Http> <URL
Name = 'source-path'>/Temporary/7a2e84d3cbf?cb68deed1cc418ca26/</URL>
<URL name = 'preview-path'>/Temporary/de2185dda1_483a65e0f8c4ad3e4327/</URL>
</HTTP>
</Protocol>
</Description>
<Transport xmlns = 'HTTP: // www.google.com/transport/p2p'/>
</Session>
</IQ>

Gtalk's new file transfer does not use the existing Jep, but takes advantage of jingle's connection advantages. Google will submit a new Jep

Connection/session management: jingle
Reliability (change something UDP-like into something TCP-like): pseudo TCP
Transfer Protocol: HTTP

There are no relevant documents for pseudo TCP. It was first used in the hello IM/photo-sharing program of Picasa to increase reliability, and has not been finalized yet.

The next version of the open-source Google Project libjingle will see the Code related to file transfer, but these methods have not yet been finalized and will likely change again in the future.