File transfers has been a long standing problem within the jabber community and the present solution using the so called bytestreams protocol is far from perfect. A kind of improvement by using symmetric streamhosts called fast mode is being used by Psi and Coccinella, but this extension was rejected by the Jabber Council (?) for reasons unknown to me. I can guess why; it is a bit complicated to implement, especially with stream proxies.
The Coccinella now has support for stream proxies, and together with fast mode it should be fairly effective in handling various network configurations. Since proxy support is also fairly common in ejabberd, I think I've timed it fairly well. One further reason I added proxy support is that people often make complaints about whiteboard transfers not working, so I thought it wouldn't be too difficult to add a new file transfer profile to ftrans/si/bytestreams. I'll ping the jdev list when I have a proposal.
I was also thinking why the bytestreams+fastmode gets so complicated when the protocol seems so deceptively clean. Lets focus on the initiator alone. There are two different flows:
They interact and depend on each other. As seen from the initiator:
where (f) means fast mode. Iq-stream (a) controls (1) and (3), while iq-stream (b) controls (2). There are three possible s5 streams:
The first succesful stream wins and kills the other.
The iq-streams do the signaling job while the SOCKS5 essentially do the media transport (except for some simple negotiating). But in fast mode this is further complicated since a CR character is sent by the initiator in the s5 stream as a signal which to pick. Sounds messy. Try write a state diagram!
After extensive testing using Coccinella as initiator and Psi as a target, I was only able to find one case where it bailed out. Coccinella had picked the fast stream, sent the CR and started writing data to its socket when Psi suddenly closed its socket. I was never able to reproduce it despite extensive tries.
I also noted that the XEP says that the streamhosts shall be tried in turn, which is very important since the proxy host shall only be used if the p2p failed. It seems, however, that Psi tries them all at once and therefore may select the proxy even if the normal or the fast would have worked. But I may have mistaken.