Question About File Transfer Extension

Smack Smack Dev
1

Hello, I have a few questions about the file transfer extension. I’ll go on record saying that I know I should RTFM, but it would save me a tremendous amount of time to not have to intimately understand each of the underlying XEPs (that’s why I’m using this API ).

And now, for my questions.

  1. Does the SMACK file transfer extension send binary data directly between two endpoints (out-of-band I think it’s called) versus through the XMPP server? If so, is it usually pretty reliable/fast?

  2. Can downloads be resumed as part of the API?

  3. What’s the difference between this implementation and Jingle really? Is one better than the other, or more appropriate for certain scenarios?

Muchas gracias

2

  1. It does both. It will transfer out of band and if a connection cannot be created between the two clients due to NAT or firewall issues then inband is utilized. It is generally fairly reliable but to be frank there are some improvements which could be made.

  2. Resuming, though part of the protocol, is not currently possible through the API.

  3. Jingle is a means of negotiating a stream between two clients, be it VOIP, video, or even files. There are some XEPs written which cover doing file transfer utilizing Jingle, though the current file transfer functionality predates jingle entirely and thus does not utilize it.

3

Thanks Alex, that does save me a tremendous amount of time. I’m really

interested in Jingle because I’m assuming the older protocol probably

uses a fair amount of server resources (for the fallback in-band

technique). I’d be really really interested in knowing what percentage

of time in-band is actually needed, but I’m assuming that would be hard

for you to say.

Speaking of Jingle, I suppose I will start digging into the

smackx-jingle libraries provided with the 3.0.4 distribution of smack.

I don’t really see much documentation included (understandable… I’m

sure you are all quite busy). Any idea if there might be any located

elsewhere?

Thanks again!

4

Thanks Alex, that does save me a tremendous amount of time. I’m really

interested in Jingle because I’m assuming the older protocol probably uses a

fair amount of server resources (for the fallback in-band technique). I’d be

really really interested in knowing what percentage of time in-band is

actually needed, but I’m assuming that would be hard for you to say.

Speaking of Jingle, I suppose I will start digging into the smackx-jingle

libraries provided with the 3.0.4 distribution of smack. I don’t really see

much documentation included (understandable… I’m sure you are all quite

busy). Any idea if there might be any located elsewhere?

Thanks again!

5

Unfortunately, I have no familiarity with Jingle and I don’t know that there is documentation that exists for it.

Alex

6

Hey Lindsay,

I wouldn’t recommend going with Jingle for file transfer. Besides that there is no standard for it and that it was superseded by XEP-0214: File Repository and Sharing you would need to implement pseudo-TCP over UDP which is not a trivial task. Instead I would recommend exploring the XEP-214 that was discussed during the last XMPP event as the way to go for file transfers.

Regards,

– Gato

7

Hi Guys,

I know this is a really old topic, but I have pretty similar questions as Lindsay had.

Lindsay/1

As i understand it now, the basic file transfer provided by a Smack extension is trying to send the actual file through SOCKS5 at first. If the Jabber server has a SOCKS5 proxy, the file is not going through the server? Is the file transported directly to the target endpoint from the source? I read that if a SOCKS5 proxy is present when the file transfer is initiated, it will be used.

Lindsay/3

Any changes about the answer to this question? I mean, if I need simple file transfering (with direct connection between peers), should I use the basic extension or the file transfer that Jingle provides.

Thanks in advance:

a newbie