By mridul on Aug 08, 2007
This has come up time and again in JIG as part of other threads, and yet we never got much farther that 'yep, we should document it'. I know of atleast one other server who have their own implementation to support this .... so maybe it is time we standardized this !
To give a basic idea of what we do:
Currently, our client supports IBB - so does the server, and the muc (which is part of the server). So idea is simple - essentially stream the data from the client to the server, store it locally (if content filtering, etc is enabled) post-process it (if enabled), and then the component streams it to the recipients.
As all the participants who can understand this are Sun IM clients - we just use IBB for now.
The caveats are obvious - potentially very heavy server traffic due to the IBB. But the main advantages are:
- The sender transmits only a single copy of the file - in comparison to a p2p model (imagine streaming a 512 KB file to a muc with 100 participants from a moderately low b/w connection).
- It will always work for all cases - irrespective of firewall, nat, etc. IBB is the lowest common denominator.
- Ability to analyze the content before sending it on to the recipients - including the possibility of archiving it (for participants who might join the room 'later').
File transfer in general was unfortunately not a very strong point in xmpp, and we are still working on the details ... so I am not very sure if we have to wait for the churn to subside, before proceeding - or start work on this in parallel, so that the requirements for multicasting file(s) to a room are kept in mind while tackling the file transfer problem.