On Spark 2.5.8, file transfers on my network were nice and speedy. Since 2.6.x, they have been so slow it’s unimaginable. Like, 1K/s slow.
I don’t have any VPN and I am using OpenFire 3.7.0. Is there an obvious bug that could be causing this?
I seem to have narrowed the issue down to Windows 7. Not sure what about Windows 7 could be causing it, but XP clients seem substantially faster.
Please observe the smack debugger closely. The file transfer may be using IBB on Win7. We were not able to reproduce the issue.
It is not a general Win7 problem. I was able to do bytestream via VPN to a 7x64 in the US from Germany.
Is your Openfire server configured to be a file transfer proxy? Is the XMPP domain name resolveable via DNS? There seems to be a similar bug (long standing) with Mac to Win file transfers.
Thank you for your help. It was using IBB, but only between Win7 hosts–not sure why.
I had to change xmpp.proxy.externalip to my domain name for openfire.
I am a little shaky on the subdomains in openfire. Does it always assume they will be:
etc.?
Is there no way to change these? I ask because the jid is still “proxy.domain.com” but the host is “chat.domain.com” (my hostname for openfire server). I suppose I could create the proxy dns entry but it seems a bit silly.
The xmpp.proxy.externalip property is not well documented or understood.
Let’s assume your JID looks like this: walter.ebeling@jabber.int.kn
the user is walter.ebeling
his XMPP domain is jabber.int.kn.
What needs to be understood, that implicitly the Openfire server assumes that all XMPP domains can be resolved via DNS. Let’s go through an example:
walter.ebeling@jabber.int.kn wants to chat to the JID joe.average@the.other.server
Openfire running at jabber.int.kn does not know were to send the chat packet. The server has to figure out the IP out the IP of the XMPP server hosting the joe.average@the.other.server. He will use a DNS name resolution to send the chat message to the.other.server. If name resolution is not working the package can not be send.The same applies to the name resolution for jabber.int.kn, if Joe replies to Walter.
The property xmpp.proxy.externalip is a containing the external IP of the XMPP server. It resolves a situation, where the IP adress can not be resolved. Which seems to be paradox, since presence is working. It might be useless, but that’s the idea behind it. xmpp.proxy.externalip should be something like 192.168.178.20. It also has to be ensured that the needed port 7777 is open in both directions for client and server.
Walter
Thanks for the information. I would say the externalip setting is clearly not useless. It allows you to specify a separate proxy server, other than “proxy.domain.com”.
The problem is basically my own fault because I did not want to create a dns entry for proxy.domain.com (actually, at first I did not know this was required, but by checking the debug of the transfer I could see it was trying to use proxy.domain.com).
Since openfire is supplying its own proxy which runs on the same server as the chat server, it stands to reason that instead of “proxy.domain.com” being the default, “domain.com” would be acceptable. Or, at a minimum, the ability to set the domain being used for the proxy. Externalip, even by its name, is clearly not for that purpose…but it does work.
Now, none of this resolves the issue I originally had. Namely, certain hosts that are on the same LAN as each other, and as the Openfire server, are not able to transfer except at exceedingly low speeds, unless the proxy server is fixed to be resolveable (either by specifying an externalip or creating a dns entry for proxy.domain.com). However, certain other hosts (Windows XP, in my test, has to be the receiver) have no problem.
My issue is resolved currently but it does raise the question of why Windows 7 requires a proxy and Windows XP does not.
Hi
sorry, but I am not sure that I got the resolution, let me wrap my understanding
Your XMPP server has the name: domain.com
A JID is: user@domain.com
You have enabled the proxy on port 7777 within Openfire. The clients can using this proxy.
The property xmpp.proxy.externalip is set to “domain.com” ?
domain.com can be resolved via DNS for all clients
Win7 is working with this setup ?
This is correct. Win7 did not work until I took this step. I am 99% sure if I added a dns entry for proxy.domain.com that would work as well.