Which JEP(s) Smack should support for file transfer

Here a summary about JEP File Transfer(original JEP cuts):


JEP-0047 In-Band Bytestream (IBB)

A protocol for bytestreaming data in band between two Jabber entities.

The basic idea is that binary data is encoded as base64 and transferred over the Jabber network.

IBB is a generic bytestream, and so its usage is left open-ended. It is likely to be useful for sending small payloads, such as files that would otherwise be too cumbersome to send as an instant message (such as a text file) or impossible to send (such as a small binary image file). It could also be useful for any kind of low-bandwidth activity, such as a chess game or a shell session.

IBB could be more desirable for many of the simple bytestream use-cases that do not have high bandwidth requirements.

  • Generally, IBB should be used as a last resort. SOCKS5 Bytestreams will almost always be preferable

  • A server MAY rate limit a connection, depending on the size and frequency of data packets.

  • A server MAY disconnect a connection that sends overly large packets as defined by server policy.

  • It is RECOMMENDED to use a ‘‘block-size’’ of 4096.

JEP-0065 SOCK5 Bytestreams

This JEP proposes a protocol that meets the following conditions:

  • Bytestreams are established over standard TCP sockets

  • Sockets may be direct (peer-to-peer) or mediated (established through a bytestreaming service)

  • Where possible, standard wire protocols are used

  • Specifically, this JEP proposes that the Jabber community make use of the SOCKS 5 protocol, which is an IETF-approved, IPv6-ready technology for bytestreams

There are two scenarios addressed by this protocol:

  • direct connection (i.e., the StreamHost is the Initiator)

  • mediated connection (i.e., the StreamHost is a Proxy)

Direct connection is the simpler case. In this situation, the StreamHost is the Initiator, which means that the Initiator knows the network address of the StreamHost and knows when to activate the bytestream.

Mediated connection is slightly more complicated. In this situation, the StreamHost is not the Initiator but a Proxy, which means that the Initiator must discover the network address of the StreamHost before sending the initial IQ-set, must negotiate a connection with the StreamHost in the same way that the Target does, and must request that the StreamHost activate the bytestream before it can be used.

JEP-0096: File Transfer

The traditional mechanism for transferring files in the Jabber community is the Out-of-Band Data protocol. That protocol has several drawbacks:

  • It is not reliable.

  • It does not work when one of the parties is behind a firewall.

  • It provides limited metadata about files to be exchanged.

This protocol defines a profile of Stream Initiation that solves the problems with out-of-band data, thus providing a robust, reliable mechanism for file transfers over the Jabber network. Implementors are referred to JEP-0095 regarding the underlying concepts of stream initiation.

In order to enable seamless file transfer and appropriate fall-back mechanisms, implementations of this profile MUST support both SOCKS5 Bytestreams and In-Band Bytestreams, to be preferred in that order.


Now the problem is: which JEP(s) Smack should support?

Matt’'s preference is IBB.

I need Smack community opinion.

I’'m waiting your answer. GO!GO!GO!

From what you posted it sounds like the “right” approach is to implement both IBB and SOCKS5, then use stream initiation to negotiate the mechanism that will work.

Regards,

Matt

hi,

I would like to know if JEP-0096 (in band File Transfer) will be supported by Smack.

Is anyone else working on this? If possible, I can contribute in this.

In general, is there any link that explains how to extend Smack?

  • Kiran

kiran,

We’'d love your help implementing file transfer. Extending Smack is pretty easy. For specific examples, see the classes in smackx. There is also documention around PacketExtensions, etc.

Regards,

Matt

Has any progress been made in supporting JEP 096 for file transfer in smack? I’‘m shopping around for a Java Jabber library and need support for file transfer. The last traffic on this thread was in July so I’‘m wondering if there’‘s been any implementation since then. I don’'t see it mentioned in the feature lists.

Thanks

Doug

Doug,

We plan to implement the JEP’'s fairly soon, but the work has not been done yet.

Regards,

Matt

The situation with file transfer is a right pain - some clients support some of the JEP’‘s, other clients other’‘s. In an ideal world Smack would support all of them for maximimum compatibility (or better still the Jabber council would make one of them an approved standard and make everybody’'s life easier).

I’'d go for IBB and SOCK5 bytestreams and JEP 96 on top, which should cover most of it.

I’‘ve attached a copy of files I’‘ve been working on for file transfer - its more of a framework and is NOT complete, but it’'s a vague start (rough OOB and IBB so far).

I’'m up for helping implement file transfer support, using any framework/code.

Pheet
filetransfer.tar.gz (65535 Bytes)

Pheet,

Very good work! We would love to include your work for the next release. When you complete your development you can send it to me.

BTW, I saw that some *Thread classes have a reference to SwingUtilities. Since Smack is a UI-less library we should need to get rid of those kind of references. That functionality could be replaced with some events that the *Thread class would raise so that listeners could react accordingly. Also make all the iv start with lower-case.

Thanks,

– Gato

Gaston,

Thank you I’'d be more than happy for the finsihed version to be included in the next release.

I can remove the SwingUtilities.InvokeLater calls and add a suitable warning in the listeners documentation regarding the Swing EDT.

It is going to be a while before it’‘s completed unfortunatley - I’'m having ‘‘fun’’ with the bytestreams protocol…

Cheers,

Pheer