antecipate: Beyond file transfer

Following the official release of the latest GTalk client, I decided to scratch the surface of its file transfer implementation. Thanks to Brian McBarron’s answer posted on the JSF list explaining how to capture a detailed log of the client’s operation (run the client with the following arguments: /log verbose tstamp thread file), I was able to confirm that the GTalk client is indeed leveraging Google’s implementation of Jingle to control file transfer. This endorsement by Google is another commitment to open standards. As shown bellow, the receiver party’s presence is probed before the transfer, in order to make sure the target client understands the transfer protocol. This is returned in the presence stanza’s capabilities extension. It is interesting to note that the capability is named “share” rather than transfer.

<presence to="juliet@gmail.com" type="probe" />

<presence to="romeo@gmail.com/Talk.v969557A95E" from="juliet@gmail.com/Talk.v95286273DB">
  <priority>0 </priority>
  <c xmlns="http://jabber.org/protocol/caps" ext="share-v1 voice-v1" ver="1.0.0.95" node="http://www.google.com/xmpp/client/caps" />
  <x xmlns="jabber:x:delay" stamp="20060817T19:50:07" />
  <status>available </status>
  <x xmlns="vcard-temp:x:update">
    <photo>ae825c56c617f83a577b0cff43611d2076358c20 </photo>
  </x>
</presence>

The next exchange uses the actual Jingle signaling to negotiate a transfer session between the parties. I have only shown the session part, as the point-to-point transport negotiation is identical to a voice transport negotiation. Note again the description namespace for the application.

<iq to="juliet@gmail.com/Talk.v95286273DB" type="set" id="31">
  <session xmlns="http://www.google.com/session" type="initiate" id="598724353" initiator="romeo@gmail.com/Talk.v969557A95E">
<description xmlns="http://www.google.com/session/share">
  <manifest>
    <file size="34314">
      <name>
        About.jpg
      </name>
      <image width="150" height="133"/>
    </file>
  </manifest>
  <protocol>
    <http>
      <url name="source-path">
        /temporary/6b82cd1ca2f333d99bad2ea07ce33f33/
      </url>
      <url name="preview-path">
        /temporary/9c6b15f343aaabea3c6a106eb72b4c80/
      </url>
    </http>
  </protocol>
</description>
<transport xmlns="http://www.google.com/transport/p2p"/>
  </session>
</iq>
<iq to="romeo@gmail.com/Talk.v969557A95E" id="31" type="result" from="juliet@gmail.com/Talk.v95286273DB"/>
<iq to="romeo@gmail.com/Talk.v969557A95E" type="set" id="49" from="juliet@gmail.com/Talk.v95286273DB">
  <session type="transport-accept" id="598724353" initiator="romeo@gmail.com/Talk.v969557A95E" xmlns="http://www.google.com/session">
    <transport xmlns="http://www.google.com/transport/p2p"/>
  </session>
</iq><iq to="juliet@gmail.com/Talk.v95286273DB" id="49" type="result"/>

FIle transfer is an important adjunct to Jingle, as it confirms the signaling can be used well beyond voice or other video communication. This is not revolutionary per say, as session negotiation and signaling has been around with SIP for some time now. But only proprietary extensions of the SIP signaling have been so far implemented when it comes to widely deployed file transfer. The use of Jingle bears the promise of a much wider adoption for a standard based file transfer negotiation. Obviously, this is only Google’s implementation of Jingle, but except namespaces, nothing in it cannot be made into a JEP. And this is what the authors of this file transfer are committed to do.

Coming back to my initial remark about the GTalk client’s naming this new feature “share”, I believe this update is only the pre-release of a larger scoped real-time experience. Brian’s post on the JSF mailing list gives a good explanation of the layered design applied to the file transfer application. By adopting this architecture, I believe Google is effectively enabling far more than just file transfer:

the transport protocol called “PseudoTCP” which is used in the p2p exchange is a Google re-implementation of TCP using UDP packets. The layered design would allow replacing this proprietary transport by a standard, such as SCTP, without disrupting the network stack so much.
the application protocol is HTTP enables interesting things such as download previews of images, resume transfers, compress files, etc. Without being full fledge web servers, a GTalk client becomes an important part in enabling a real time collaboration application. Linking it to a workstation’s browser through some toolbar plug-in is probably not that difficult, and would makes an XMPP backed real time photo sharing and comment experience much more compeling than their web only siblings.

Although this latest release has received unjustified bashing from many ignorant self proclaimed visionaries, I believe on the contrary that it is paving the way toward wider scoped real time standards-based sharing services for communities, open to any and all that wish to interoperate with them.