Opened 11 years ago

Closed 10 years ago

Last modified 10 years ago

#6183 closed patch (fixed)

Support In-band bytestreams (IBB) method for file transfers on XMPP

Reported by: malu Owned by: deryni
Milestone: 2.6.0 Component: XMPP
Version: 2.4.2 Keywords: XMPP in-band bytestreams file transfers
Cc: mcepl, datallah, CiaranG

Description

This ticket is about adding support for IBB for file transfers on XMPP as a fallback method when a socks5 bytestream is not possible to established. Actually XEP-0096 states that clients MUST support both these methods.

So I have started to implement this in libpurple... I'm trying to design the "IBB module" to be resuseable, I'm thinking about the possibility at some point to support it as a Jingle transport method, among others...

I will submit a patch here as soon as I have something working, and depending on how much work there is on my other libpurple-related commitments (foremost vv and xmpp custom smileys) :)

Attachments (3)

pidgin-ibb-2008-07-06.diff (37.1 KB) - added by malu 11 years ago.
Patch implementing support for IBB file transfers
pidgin-ibb-2008-07-12.diff (41.6 KB) - added by malu 11 years ago.
Now it should actually have a chance of working…
xmpp-ibb-win32-fix.patch (807 bytes) - added by phannent 11 years ago.
Small win32 fix

Download all attachments as: .zip

Change History (14)

Changed 11 years ago by malu

Patch implementing support for IBB file transfers

comment:1 Changed 11 years ago by malu

I have attached a first patch implementing in-band bytestreams as an alternative when doing file transfers on XMPP. It will still probably need more testing, since I've only done some testing locally, to test more scenarious.

Also one thing I'm planning is to make it "rember" if socks5 has failed before for a given JID, and in that case just revert to IBB without trying socks5 again (to avoid an unnessary time-out wait). This would only be "rembered" within the current session.

comment:2 Changed 11 years ago by Sim-on

  • Type changed from enhancement to patch

Changed 11 years ago by malu

Now it should actually have a chance of working...

comment:3 Changed 11 years ago by malu

I've fixed this up so that now it should kinda work... Actually I've realized that XEP-0096 doesn't really handle the case when socks5 fails failes. So this patch fixes connecting a file transfer using IBB (XEP-0047) when the receiver doesn't support socks5. It also tries to initialize an IBB transfer using the same ID as the file transfer if the receiver supports IBB. This will at least work if the two clients are libpurple-based in the case socks5 fails.

comment:4 Changed 11 years ago by malu@…

(In 1004ee62a91cd7c1f39c9d5aafdbe4de761879b0):
Implements file transfers using in-band bytestreams for XMPP using XEP-0047 Refs #6183

Changed 11 years ago by phannent

Small win32 fix

comment:5 Changed 11 years ago by phannent

Daily builds are up and running: http://hannent.blogspot.com/2008/09/pidgin-xmpp-testing.html

It would be better to have a branch called im.pidgin.xmpp.testing or im.pidgin.patches for me to build and test against. That way patches could be propagated to im.pidgin.pidgin in completion of changes. The next patch after this to test could be the attention one: #3173

That way patches don't bit rot.

comment:6 Changed 11 years ago by phannent

The latest builds of this are working perfectly.

comment:7 Changed 10 years ago by rekkanoryo

  • Owner changed from nwalp to deryni

Currently all that is blocking this being merged to im.pidgin.pidgin is a code review.

comment:8 follow-up: Changed 10 years ago by evands

In what branch is this currently committed?

comment:9 in reply to: ↑ 8 Changed 10 years ago by malu

Replying to evands:

In what branch is this currently committed?

It's in the branch im.pidgin.cpw.malu.xmpp.ibb_ft

comment:10 Changed 10 years ago by malu

  • Resolution set to fixed
  • Status changed from new to closed

comment:11 Changed 10 years ago by datallah

  • Milestone set to 2.6.0
Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!