So, it seems that the file tranhsfer issue might be because of the google non xmpp compliant after all. I have tested the spark file transfer using the jivesoftware.org for 30MB and it works fine at the first time(I don’t think, I have to test more than that cause Jive is not going to release it without testing it tehmselves.) As, I am doing file transfer using jivesoftware.org, I watch the network traffic over wireshark. I notice that the file goes to the jivesoftware.org server first and then it comes to the other client from the jivesoftware.org server.
So, I try again with the google server and spark for file transfer. Lo, I am, some how, using port 443(https port) in the advancced setting and getting the https refuse errors. So, I change it to port 5223. Yet, it still stuck at 60KB. google use jingle for its own file trnsfer and yet spark used to be able to do file transfer on google before (I have seen forum thread). But not anymore ?
Smack itself is able to do file transfer for a a very small file size on google with mix result tho. I am able to transfer 1.7MB while the debug is enabled but not when debug is disabled.
I have only been seeing IBB transfer since I am developing in a single box with both clients running.
Here is a better explaination from Alex
If I can get a little more information about your specific use case maybe we can together determine a solution for your needs.
Why don’'t you want to setup a proxy service?
The difficulty of sharing files between users on seperate LANs is that the address’'s, unless operating under a VPN, need to internet addressable. In other words one user needs to be able to see the other user to directly connect to them. When a user is on a LAN their address is generally translated to match one internet address.
That is the power of the proxy service as both users connect directly to the proxy and the proxy mediates the file transfer. In this case, you only need one internet addressable node, the file transfer proxy.
Jabber file transfer, and in this case Spark, also provide a fall back mechanism which is known as IBB. Which transfer’'s the file over the same XML stream used by Jabber. The problem with IBB is that there is quite a bit of overhead. Each packet of data is encoded in Base64… the addressing information is added… the packet has to be routed through your server and any remote servers. So, if you are transfering large files, or even a fair amount of files it can be problematic as it creates a huge burden on the server. In fact, several sever implementations I have heard have out-right banned IBB because of the congestion it creates. It really does have the potential to slow down and cripple a server. So my question in this case would be, how many files are you planning to transfer and how large are they?
The user’'s on seperate LANs, would there be a way to setup a NAT for them to route from a specific port to a specific computer? How many clients do you have behind each LAN?
If we can figure some of these things out, it should be easier to determine what you need and if it is possible.
So, my judgement has been rushed.I will update the thread as I test out the file transfer with p2p.