Does that Hex dump always look the same? The dump that you provided spells out “”, followed by a NULL character (00). This last character is disallowed, and is what is causing the exception to be thrown.
If the problem always occurs in relation to the “policy-file-request” fragment, you might have identified the cause of the problem. If I recall correctly, this fragment is related to the cross domain stuff required for Flash connections. Are your users using a Flash (XIFF?) based client? Is the problem limited to those users perhaps?
If the client sends invalid data, the correct way for the XMPP domain to respond is to disconnect that client. You are right that this problem corresponds with the complaints about clients being disconnected that you’ve been receiving.
Yes I believe this is the exact reason - we are using XIFF and VERY often the connection doesn’t work on the initial request and we revert down to a BOSH connection.
If you try a few times a direct socket connection will work. It sounds like Openfire is being too sensitive about this?
But why would flash be sending out invalid characters in the cross domain policy request?
Is there any way I can fix that - it is all automated within Flash.
If we’ve correctly identified the problem, it’s caused somewhere in the realm of Flash/XIFF. I’m afraid I can’t help you there (I’ve got no experience with the XIFF client library). I think it’s time someone else jumped in this discussion. Perhaps you can search the XIFF dev/support community for related problems, or ask a couple of those developers to have a look at your issue.
I think the issue is actually with the way Openfire is responding to these cross domain requests - just not very compatible with the latest version of Flash and seems to fail about 50% of the time. It is even happening on our staging servers right here in our office.
Hopefully someone from Ignite can look into it. I am sure others must be having the same problem?
The problem appears to be thrown very early (could you provide a stackdump so we can verify this?). The exception seems to occur at the point where the server picks up the raw bytestream from the socket, and tries to convert it into Java XMPP objects. These routines are largely handled by Apache MINA. There’s not a whole lot of ‘Openfire’ going on there.
Basically, MINA is trying to convert the received bytes into characters, which are later converted into XML and XMPP stanzas. The NULL character is most likely not allowed in the XMPP stream (by protocol definition). If MINA processes such a received character, Openfire is right to close the connection.
My first bet is still that the client is simply sending incorrect data. On the other hand, perhaps the NULL character is allowed in a specific context (e.g. multi-byte character representation?), which Openfire fails to handle correctly.
Can you provide packet dumps (Wireshark, tcpdump?) made on a client (non-encrypted/compressed, of course) that suffers from the problem? It’d be interesting to what the client is actually trying to send to the server.
Before I start the low level traffic analysis etc I found some more interesting info on this.
As you probably know the Hexdump is “” terminated by a null character - which is exactly what Flash should be sending.
What is strange though is that this is happening on port 5222 when the socket policy file server is running on port 5229. The only reason why Flash would be making a policy file request to 5222 is if the request to 5229 failed. Port 5222 shouldn’t be serving out policy file requests anyhow which I assume is why it can’t handle the null terminating character.
So the real issue here is why port 5229 is failing to serve back the policy file about 30% of the time on our servers.
Is this a problem in Flash or Openfire?
We may attempt to create an independent master policy file server on port 843 but this would be a major hack.
We are running our site on Windows Server 2003 and have this issue on both our dev and live environments.
We are still getting thousands of these errors and related connection problems.
2008.11.11 12:00:52 Closing session due to exception: (SOCKET, R: /139.168.58.49:3487, L: /118.127.73.10:5222, S: 0.0.0.0/0.0.0.0:5222)
Interestingly you can see above, that the null character error is on port 5222 which is the jabber socket port and not the policy file port. So Flash is attempting to get the policy file from the correct flash policy request port 5229 - but fails for some reason (this is where the problem is).
Flash then attempts to get the policy file directly from port 5222 when you make the jabber connection which throws this error as port 5222 doesn’t serve policy files. So this error would be expected.
Can anyone confirm that this is actually the issue?
And does anyone have any ideas why port 5229 keeps failing to provide the cross domain policy file to Flash.
(We are using Windows Server 2003)
I have noticed a lot of people are having this issue in the forums but I can’t see any solution. (Using BOSH is not a solution.)