[Vysper] XMPP BOSH - Week 5

[Bogdan Ciprian Pistol <bo...@gmail.com>]

Week 5 - status report (http://vysper-gsoc2010.blogspot.com/2010/06/week-5.html)

The following tasks were scheduled for this week:

    * SASL auth
    * Resource binding
    * Figuring out a general approach for routing stanzas to Vysper
and back to the BOSH client

Completed:

    * SASL is done

    * Session restart after SASL auth is implemented. It does not
forward the restart request from the BOSH client to Vysper, but
instead responds with the approriate features from
ServerResponses#getFeaturesForAuthentication(). The method is private
and I changed it (in the patch) to be public. If you think this is not
appropriate I will strip instead the response from
ServerResponses#getStreamOpener().

    * Improved continuation implementation and "expires" (BOSH wait)
times. There was a problem with the previous continuation
implementation of "expire" because the "resume" on an expired
continuation (that has not "completed") is implicit (by Jetty) - and
now I use continuation listeners for expired requests that attach the
result to the continuation and then implicitly (by Jetty) in the
servlet doPost() I write the result (empty response) as if it were
resumed by me.

    * Accumulated stanzas (more than the requests/responses available
- in code are stored in "delayedResponseQueue") are merged into a
single request for better efficiency (bandwidth, latency). There is a
potential problem here because some responses have specific attributes
that are problematic to merge, but actually this is not a problem
because only the session creation response and session restart (after
SASL auth) are in this case. The server and the client are not sending
extra req/resp in the SASL/restart phase and are waiting the response
from the other, so everything works OK with merged stanzas.

    * Thread safe BoshHandler and BoshBackedSessionContext. (part of
the work was done earlier) If some client(s) send multiple requests
with the same SID then it is possible to have simultaneous requests in
BoshHandler, so BoshHandler is guarded by this by synchronizing on the
BoshBackedSessionContext (that is uniquely identified by its SID).
Also the writes coming from Jetty (when a continuation expires) and
from Vysper are also synchronized on the BoshBackedSessionContext,
this makes the BoshBackedSessionContext thread safe. When the session
is created initially in BoshHandler in doesn't need to be synchronized
because nobody knows the SID, also the "happens before relationship"
memory consistency is in-place because of the ConcurrentHashMap used
to store the session.

    * The write requests of stanzas from Vysper are wrapped inside a
body wrapper before being sent to the clients.

    * The stanzas from BOSH clients are stripped from their body
wrapper and sent for processing to Vysper.

 Patches:

    * https://issues.apache.org/jira/browse/VYSPER-214

Next:

    * continue the client side implementation based on Strophe.js


Bogdan

Re: [Vysper] XMPP BOSH - Week 5

[Bogdan Ciprian Pistol <bo...@gmail.com>]

Hi Niklas,

On Tue, Jun 29, 2010 at 11:33 PM, Niklas Gustavsson
<ni...@protocol7.com> wrote:
> Good work. Would it be possible to increase the frequency of patches
> (and thus have smaller, more isolated patches which are easier to
> review)?

Yes, I will try to have the patches more smaller and feature oriented
(not to have many features in one patch), thanks for reminding me.

> On a different note: we need to get unit tests in place. Could you fit
> this into the next week? I'm worried we're designing the code without
> thinking about testability.

Ok, I will include the JUnit tests too.


Bogdan

Re: [Vysper] XMPP BOSH - Week 5

[Niklas Gustavsson <ni...@protocol7.com>]

Good work. Would it be possible to increase the frequency of patches
(and thus have smaller, more isolated patches which are easier to
review)?

On Tue, Jun 29, 2010 at 1:00 PM, Bogdan Ciprian Pistol
<bo...@gmail.com> wrote:
>    * Session restart after SASL auth is implemented. It does not
> forward the restart request from the BOSH client to Vysper, but
> instead responds with the approriate features from
> ServerResponses#getFeaturesForAuthentication(). The method is private
> and I changed it (in the patch) to be public. If you think this is not
> appropriate I will strip instead the response from
> ServerResponses#getStreamOpener().

I think it makes sense to have this as a public method.

On a different note: we need to get unit tests in place. Could you fit
this into the next week? I'm worried we're designing the code without
thinking about testability.

/niklas

Re: [Vysper] XMPP BOSH - Week 5

[Bogdan Ciprian Pistol <bo...@gmail.com>]

Hi Fernando,

On Tue, Jun 29, 2010 at 7:36 PM, Fernando Padilla <fe...@alum.mit.edu> wrote:
> I know I mentioned earlier the capability to serve up a "crossdomain.xml"
> file easily, and it sounded like everyone agreed, so this might already be
> done.

Yes, this is implemented.

> Another cross-domain enabling feature to add at the very bottom of the
> feature list is to support native XDR, via supporting special headers. The
> standard is described here:
>
> http://developer.yahoo.com/yui/3/io/#xdr

As I understand from the link you provided XDR is using Flash or
native XMLHttpRequest (available only on some browsers) in the
back-end.

Flash crossdomain.xml and native XMLHttpRequest (with the special new
HTTP headers) are both implemented.

Bogdan

Re: [Vysper] XMPP BOSH - Week 5

[Fernando Padilla <fe...@alum.mit.edu>]

I haven't been following the BOSH effort in full detail, but I wonder if 
the cross-domain support has been documented somewhere in the "feature" 
list for BOSH. :)

I know I mentioned earlier the capability to serve up a 
"crossdomain.xml" file easily, and it sounded like everyone agreed, so 
this might already be done.

Another cross-domain enabling feature to add at the very bottom of the 
feature list is to support native XDR, via supporting special headers. 
The standard is described here:

http://developer.yahoo.com/yui/3/io/#xdr




On 6/29/10 4:00 AM, Bogdan Ciprian Pistol wrote:
> Week 5 - status report (http://vysper-gsoc2010.blogspot.com/2010/06/week-5.html)
>
> The following tasks were scheduled for this week:
>
>      * SASL auth
>      * Resource binding
>      * Figuring out a general approach for routing stanzas to Vysper
> and back to the BOSH client
>
> Completed:
>
>      * SASL is done
>
>      * Session restart after SASL auth is implemented. It does not
> forward the restart request from the BOSH client to Vysper, but
> instead responds with the approriate features from
> ServerResponses#getFeaturesForAuthentication(). The method is private
> and I changed it (in the patch) to be public. If you think this is not
> appropriate I will strip instead the response from
> ServerResponses#getStreamOpener().
>
>      * Improved continuation implementation and "expires" (BOSH wait)
> times. There was a problem with the previous continuation
> implementation of "expire" because the "resume" on an expired
> continuation (that has not "completed") is implicit (by Jetty) - and
> now I use continuation listeners for expired requests that attach the
> result to the continuation and then implicitly (by Jetty) in the
> servlet doPost() I write the result (empty response) as if it were
> resumed by me.
>
>      * Accumulated stanzas (more than the requests/responses available
> - in code are stored in "delayedResponseQueue") are merged into a
> single request for better efficiency (bandwidth, latency). There is a
> potential problem here because some responses have specific attributes
> that are problematic to merge, but actually this is not a problem
> because only the session creation response and session restart (after
> SASL auth) are in this case. The server and the client are not sending
> extra req/resp in the SASL/restart phase and are waiting the response
> from the other, so everything works OK with merged stanzas.
>
>      * Thread safe BoshHandler and BoshBackedSessionContext. (part of
> the work was done earlier) If some client(s) send multiple requests
> with the same SID then it is possible to have simultaneous requests in
> BoshHandler, so BoshHandler is guarded by this by synchronizing on the
> BoshBackedSessionContext (that is uniquely identified by its SID).
> Also the writes coming from Jetty (when a continuation expires) and
> from Vysper are also synchronized on the BoshBackedSessionContext,
> this makes the BoshBackedSessionContext thread safe. When the session
> is created initially in BoshHandler in doesn't need to be synchronized
> because nobody knows the SID, also the "happens before relationship"
> memory consistency is in-place because of the ConcurrentHashMap used
> to store the session.
>
>      * The write requests of stanzas from Vysper are wrapped inside a
> body wrapper before being sent to the clients.
>
>      * The stanzas from BOSH clients are stripped from their body
> wrapper and sent for processing to Vysper.
>
>   Patches:
>
>      * https://issues.apache.org/jira/browse/VYSPER-214
>
> Next:
>
>      * continue the client side implementation based on Strophe.js
>
>
> Bogdan