Hi,
Are there any ways to do file transfer with smack?
Thanks,
Ati.
Ati,
Smack doesn’‘t specifically support file transfer. However, you can attach arbitrary Java objects to each message. So, you could use this feature to send large byte arrays (which could be used for file transfers). That method wouldn’'t really be a standard usage of Jabber servers, since most files are transferred out of band (OOB) via peer-to-peer (since large messages can bog down a server).
Can you be more specific about what functionality you’'re looking for?
Regards,
Matt
Hi,
I’'d like to do OOB file transfer. If I understand the specification correctly it works (after a successful HTTP PUT) like this:
<iq type=’‘set’’ id=’‘file_1’’ to=’‘recipient@jabber.com/home’’>
<query xmlns=’‘jabber:iq:oob’’>
<url>http://files.jabber.com/testfile.txt</url>
here is the file!
So I’‘d like to know what’'s the correct way to create the above message with Smack.
Thanks,
Ati.
There is no ‘‘out of the box’’ method of adding extensions. However, if you look at the existing Smack iq code, you’‘ll see that it’'s pretty easy to create your own class for supporting other protocols.
FYI, oob and pubsub are the two most controversial protocol areas now under development. The old oob is not meeting most people’‘s needs but the JSF membership is having trouble deciding on what the next oob protocol should be. If you look at the jep list, you’‘ll see there are several competing standards under consideration. The community is supposed to try and define some overall plan but that hasn’'t happened yet. So things are currently pretty up in the air.
The simplest is oob as it currently stands which requires you to setup some URL server (http being the most common) on the client sending the file. This has all sorts of problems with firewalls and security so PASS was intended to allow proxying. But that has also proven pretty impractical to use.
Current alternatives are suggesting SOCKS streams, raw sockets, etc.
I actually would love to propose JXTA ( http://www.jxta.org ) as an oob p2p file exchange protocol but haven’‘t had the time or desire to do it. JXTA would be especially easy for us because JXTA’‘s Java implementation is robust and extremely well tested (and released under the BSD license). In addition, JXTA allows robust proxying, firewall penetration, lookup, search, etc and would add the dimension of file sharing and p2p that would be a nice compliment to xmpp’'s client-server architecture. So xmpp for ‘‘command and control’’ and other coordination tasks where you know the person your talking to and JXTA for exchanging files and doing other things p2p (actually, I was thinking that secure end-to-end exchanges should be done p2p over JXTA rather than over xmpp where the server is a known vulnerability).
Basically there’'s things that are ideal for client-server (xmpp) and p2p (JXTA) so would love to add a p2p protocol as a standard compliment to xmpp.
For your immediate needs, the only standard right now is iq:oob and PASS but it’‘s not a great solution and those implementing it right now find it’‘s not reliable or well used. So you can implement it (it would be trivial with Java) but raises security issues and doesn’'t work too well.
Good luck.
-iain
Iain,
Thanks for the quick summary of the alternatives.
I don’‘t think that oob is a good solution, but it fits into my needs (currently I could not find any better) so I’‘ll try to implement it. I’'ve got some ideas which will make the system more secure against unauthorized access but these are dirty hacks, not real solutions.
Thanks again,
Ati.
Ati.
You’‘re welcome. I’‘d love to hear how your efforts turn out. If you have time, please report back to the forums. I’‘m sure I’‘m not the only one that would love to learn the pro’'s and cons (and workarounds) you encounter.
-iain
I hope I’‘ll find a good solution. I’'ll write about it soon.
Regards,
Ati.
I am actually working on some in-band data transfer extensions to smack. Once I get them completed, I’'ll try and publish a document that describes how I finally accomplished it.
A couple of things that I do know are:
-
In band transfers are not good for large files, unless they are broken into chunks which makes for a sequencing headache on the client end.
-
If using some sort of MIME or Base64 with chunking, you wind up with most of your segment window being eaten in encoding data and not in actual file data.
Any in-band transfer would by its very nature be a non-standard extension.
Hi,
In band transfer can be very tricky because different servers have different resource sharing rules that may reject packets because of too much bandwidth usage, too many packets per time period, or too big a packet. So your protocol needs to be careful about working around these limitations.
The only standard for ibb is JEP 47
http://www.jabber.org/jeps/jep-0047.html
But there has been a lot of controversy about it. So if you do implement ibb, try 47 but be prepared for the proposal to not pass standardization. It’'s better than rolling your own solution though.
You may also want to look at JEP 52
http://www.jabber.org/jeps/jep-0052.html
that describes a way to negotiate the file transfer. It may help to make your file transfers a little more reliable.
Good luck an let us know how things work out.
-iain
The target for this mechanism is really going to be internally controlled corporate servers (and their interop), so some of the resource usage concerns are less critical, but I will definately look at the JEP’'s and take those into account.
It may be quite a while before I get it complete, since I have OOB transfers working so it’'s more or less on the middle burner, but steadily progressing. As an aside, I see you (jive software) are in Escondido and we (Cotelligent) are in San Diego. Are you going to be hosting any sort of smack users forum or technical forum so that those of us who are working with the library might meet some of the faces who are creating it?
It may be quite a while before I get it complete,
since I have OOB transfers working so it’'s more or
less on the middle burner, but steadily progressing.
Ah. Understood. If you have oob working ibb would definitely be in the ‘‘nice to have but not necessary’’ pile.
As an aside, I see you (jive software) are in
Escondido and we (Cotelligent) are in San Diego. Are
you going to be hosting any sort of smack users forum
or technical forum so that those of us who are
working with the library might meet some of the faces
who are creating it?
Excellent suggestion. I’‘d love to have a Smack (and Messenger) get together. I was hoping OSCON would have been in SD again this year but it went up to Portland. The Jive head office is in New York City but I’‘ve been campaigning to have the company retreat in SD (and trying to get them to move out to the west coast - heh). We could definitely hold a little dinner or something if that works out. Otherwise, Jive usually holds a little get together at JavaOne. If you go next year, or are just in San Francisco around that time we definitely should have the Smack group join that. We’'ll post an announcement to the forums and on our home page.
-iain
Steven,
Actually, Jive Software is in New York, NY but Iain happens to be in San Diego. So, there’‘s the possibility of meeting up with Iain out there. Maybe I’'ll make a trip out there before too long though.
-Matt
Otherwise,
Jive usually holds a little get together at JavaOne.
Finally, the excuse to go to JavaOne that I’'ve been looking for!