[Standards-JIG] File transfer in MUC
jd.conley at coversant.net
Fri Oct 13 21:55:20 UTC 2006
> My idea is that there is tcp for files and building another tcp inside
> app is wrong (at last, duplication of work, and your tcp will probably
> not be so good, it too quite some time to develop decent flow control,
> and you do not have access to flags like don't fragment in the app).
P2P TCP is the ideal situation (that's why S5B is on my list), but it's
often easier to get other things through NAT's if you're talking
consumer level applications.
> And, if you want to imitate torrent in the way who downloads anything,
> shares it to others from that moments, it has two big problems:
> a) difficult to implement
True. So is RTP, ICE, XMPP.
> b) half the net admins will forbid such application from their
> p2p transport is usually OK, but sharing for others if not explicitly
> set by user is not.
This can easily be achieved in security conscious implementations with
administrative policies by monitoring/manipulating the control channel
(XMPP). How about if the admins set it up to allow sharing to others
only on internal domains but not to external? That seems reasonable.
I still think a distributed algorithm is the best technology for the job
when it comes to quickly and efficiently broadcasting content without
having one bandwidth bottleneck.
More information about the Standards