GSoC 2008 Report: Openfire and SparkWeb

Blogs Ignite Realtime Blogs
1

I am working on BOSH support of Openfire and SparkWeb as part of the Google Summer of Code 2008. As we got past the midterm evaluations, my mentor Gaston and I thought it would be good to inform the community about what I have done so far.

My proposal involved updating and improving Openfire’s BOSH support by updating the implementation to BOSH 1.6, and migrating Apache MINA as its connection provider.

I started with creating a load test environment to see Openfire’s current performance, and created a document explaining how to use it. Then I ran some load tests using that environment. Unfortunately, the test machines I used were not enough to produce desired results.

As the next part of the project, I updated Openfire’s BOSH to support both 1.5 and 1.6. Here is a summary of the update:

  • Added ‘hold’ and ‘ver’ attributes to the session creation response.

  • Fixed version checking. Before it was done using a double variable, which may show that 1.5 is newer than 1.10.

  • Script syntax support has already been added before. Finetuned it to prevent caching of responses.

  • Implemented in-order message forwarding (JM-1412), because further work seemed to be depend on this implementation. This is the part that took most of my time, also which made me to get more familiar with the code after long debugging sessions.

  • Implemented acknowledgements, which was intoduced in version 1.6.

  • Added support for session pauses, which was also new for 1.6.

  • Implemented overactivity checking. In 1.5, there was only ‘polling too-frequently error’, and a little description about it. Version 1.6 introduced a new section for overactivity, and has a detailed description of which circumstances should be considered overactivity.

With this update, I have seen that some BOSH issues I was not aware of (JM-1245, JM-1246) have also been resolved. The update has been merged into Openfire trunk, so you can grab and test it.

After the update, I started to investigate how to migrate to Apache MINA, and found out that it would be harder than we expected, because the version used by Openfire, 1.x, did not have any http support. We had also other alternatives, like Grizzly, so we deferred the decision about connection providers until we do some tests on them.

I am currently working on SparkWeb to make it fully compatible with BOSH 1.6. In the meantime, I am cooperating with Tomas Karasek, who is developing BOSH for Gajim, to resolve any BOSH related issues in Openfire.

I am open to any ideas/suggestions.

2

as you work on sparkweb, can we get ssl working properly

3

Sounds great Good BOSH support in Openfire, SparkWeb and other clients is essential for using Jabber in «hostile» corporate environments. Getting this to work would really help a lot in my company.

4

jledhead: What SSL issue are you referring to?

5

I haven’t tried the most recent version, but my openfire server requires tls and I couldn’t get it to work reliably. Something along the lines of this post http://www.igniterealtime.org/community/thread/32685

6

Hey jledhead,

I think that two things are being mixed in that thread. One scenario is Sparkweb using standard TCP connections to port 5222 and using startTLS and the other scenario is using BOSH (i.e. HTTP) in a secured way (i.e. HTTPS).

David’s response was about the former case. Regarding the latter I think that there is a confusion in the admin console of the server. You can configure the client security to require TLS but I don’t think that is related to BOSH. I would probably expect that if TLS is required the HTTP port is disabled and only HTTPS is enabled.

What do you think?

– Gato

7

Is there any chance that you will also add BOSH support to Smack? That way Spark clients and custom clients could also benefit from these features.

8

Hi,

Is it possible that requests the client make will get to the server in the wrong order?

Maybe when the server is busy and the client send requests fast enough?

How does openfire handle it?

Do you think that the client should verify that requests aren’t being sent too fast or is it the server responsibility.

9

Hi dror,

JM-1412 resolved the issue you mentioned. The server should expect the ‘rid’ attribute to be within a window of values greater than the ‘rid’ of the previous request. The size of the window is defined by the ‘requests’ parameter.

Openfire now handles it this way:

If a request with ‘rid’ attribute greater than expected arrives, openfire holds it in the queue and waits for another request. When all requests in the sequence have been arrived, openfire processes and responds to them in correct order.

10

Hi,

I’ve recently noticed a strange scenario in Openfire/Jetty.

Can you tell me How the BOSH module behaves when I resend a request (same RID)??