[GSOC] File Transfer Support for libpurple.

[Ashish Gupta]

Hi!

The coding phase for GSOC '13 has officially ended. These three months have
been enlightening, tiring and rewarding, all at the same time. Waking up to
an open emacs window, and sleeping looking at debug logs has it's merits.

If you don't know, My project's aim was to implement (or fix) :

File Transfer support for Yahoo!
File Transfer support for Google Talk.
Develop a Protocol Agnostic File Transfer Plugin.

I initialy started off by looking at the code for the Yahoo! prpl. It
seemed complex at the first glance, but soon started making sense. Most of
the things were intact but Yahoo! had managed to break the File Transfer by
changing the length of the xfer_id we send to the Yahoo! server for
authentication from 24 to 44  as well as enforcing that the last character
of the xfer_id always be a '='.

sulabh.dev and rekkanaryo helped with their experience on the same and this
resulted in a quick fix, taking a tiny fraction of the anticipated time.
Yahoo! file transfer Works.

Onto Google Talk.
Since the morale was high (Yahoo! FT was just working correctly), I dived
into the code (libpurple/protocols/jabber/google directory). I tried to
figure out what was happening, but couldn't . File Transfers refused to
work, no accept requests, no rejected requests, nothing at all.
The initial plan was to implement "libjingle" that Google Talk uses. As far
as I knew back then, it was supposed to be something close to XEP 0234 that
describes how Jingle works. WRONG. It was quite different. Took a major
chunk of the time just to figure out the flow.

Scourging the Internet for anything relevant to GTalk FT, I gave up hope.
Google's documentation on libjingle and the sample file transfer
applications didn't help at all, but ate up some time. Nothing gained
there. Tried looking through the existing implementation for Audio/Video
calls in jabber/google/google_session.c, but to no avail again.

pidgin -d can save your life.

Instead of working forward, I started thinking in a reverse manner (and
realized, this is exactly what I should have done long ago). I made Google
Talk initiate the file transfer and study the debug log closely. Expectedly
enough, it was sending out XML stanzas containing file descriptions. This
finally meant a start. I started mimicking the exact process and sent back
to GTalk whatever it sent to me, just to know what the next leg in the
process would be. This cycle helped for a while, but then all of the
development came to a sudden halt.

The obstacle here was the candidate exchange phase, where each party sends
out a list of possible candidates (IP:Port pairs) that they want to use for
the file transfer session.Not knowing where to start,  I was stuck.
Completely, Absolutely, Stuck. With nowhere to go, and no help flowing in
from anywhere (maybe because anyone I talked to had no experience with
Google Talk FT), I set out to traverse the NAT myself, treating the file
transfer session as a media session and trying to use PurpleMediaCandidates
as a possible solution. Tried to use farstream, but it needed a specific
media type , which I obvisouly didn't have, this being a non media
session.  Nothing worked. google_session.c was turning into a mess. All of
this gobbled weeks to no end. The morale was low and time was running out.

libnice to the rescue!

Finally, one day I stumbled across libnice and thought, WHAT THE HELL,
maybe this will work out. With some patience, it actually did! NiceAgent is
actually something very useful that will do all your work for ICE
Processing when traversing a NAT, and gather candidates that you can send
out.
This resulted in cleaning up the code (which had become a big untidy mess
with all kinds of comments all over)., and isolating parts of the file
share session from the rest of the media code in google_session.c
I was successfully able to send a file from one machine to another using
GTalk, and when the md5 checksums matched on both ends, I rejoiced to no
end. Sending a file to an outer machine (outside my LAN) didn't work out
that well though.

The protocol that Google Talk makes use of has now been documented at
https://imfreedom.org/wiki/GoogleTalk
Hopefully, it will help a stray developer who's trying to find information
on GTalk FT.

Lastly, I implemented the cancel functions for handling a remote cancel for
the xfer, cancelling it on the local end, ran into mutual infinite
recursion (witnessed it for the first time :D ), and fixed it.

And doing all of this (what you read is only a fraction of the whole
excruciatingly fun experience) took time. The initially planned File
Transfer plugin is not even in the picture as of now. I hope I can continue
to work on this, even well after GSOC has ended and finish the remainder of
the GTalk FT as well as work on the plugin.

If you've reached till here after reading so much, thanks a lot, you've
just seen GSOC '13 through my eyes :P

Current Status:
Yahoo! FT works.
Google Talk FT works but is limited to LAN clients for now.

A big thanks to all the Pidgin developers and contributors (helping me with
the silliest of my questions on #pidgin as well as the XMPP conference
room) (elb, QuLogic, datallah, bleeter,malu,Tomasz and all the others).

A very special thanks to Mark, who has constantly been there right from the
start and helped me a lot with everything (the pidgin code, the
application, the repository fiasco, the morale support), actually being
what an ideal mentor should be :)

Also, to Eion Robb who helped me put up the inital application together and
helped test Google Talk transfers while offering advice on how to proceed
throughout.

Thanks a lot for letting me work on this, guys!

To sum it up, it was the best experience I've had as a developer and I
continue to look forward to other opportunities to contribute to FOSS.

PS - The repo is located at hg.pidgin.im/soc/2013/ashmew2/filetransferY .Do
have a look and please let me know if you have any suggestions. I'll be
continuing work on this project :)

Regards,
Ashish Gupta
Student for GSOC '13.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/pipermail/devel/attachments/20130925/adbf2e0c/attachment.html>