Unfortunately I couldn't take part in the session as I was talking
about a security at the time.
However I have implemented a Tigase Bosh component and have also
experienced a few problems which have been solved in one or another way.
Let me elaborate on the session collision issue a bit to make it more
clear as I think I am the only one who really tested it and know what
exactly is going on.
First of all in a standard Bosh use case when we precisely stick to the
Bosh spec there is no session collision. The session collision is
related
to the issue with page-reload handling.
Normally when the web page with JS client is reloaded the client has
no way to remember anything and it starts fresh and tries to reconnect,
re-login and other re... actions. This however causes several problems:
1. If there were chat windows open all the chat history is lost
2. On the busy installations each page reload causes have load on
the server as the client reconnects, loads the roster, refreshes
presence
status and so on.....
To workaround above problems the client stored SID and RID in cookies
and on page reload it reads the cookie and tries to connect to the old
Bosh session. The user roster, presence information and old chats
content
can be loaded using the Tigase Bosh cache extension described here:
http://projects.tigase.org/server/trac/wiki/BoshSessionCache
The new problems of course appears on the opening a second/third
tab/window in the browser. In each new tab/window the JS client
"thinks" it was a page reload and tries to connect to the old session.
The Bosh server receives a new connection from the client and tries
to close other waiting connection. Then the client on the OLD tab
opens new connection and the Bosh server closes connection for
the NEW tab.
This causes problem on the client side that you never know in which
TAB the new messages end-up.
But there is even bigger problem on the server side because the
it causes high load by the Bosh server continuously closing opening
Bosh connection. (Assuming we don't use keep-alive).
The problem therefore must be solved on the server side and I think
this is the only place where it can be resolved.
This is because it is actually possible to detect session conflict on
the
Bosh server side.
Both JS clients fighting with each other for an access to the Bosh
session
have own RID counters therefore every new Bosh request from one client
is repeated with the same RID by the other client.
It is possible to detect this on the server side and terminate one of
the
clients. This is what Tigase tries to do and this also works quite
well.
Artur
So far so good, it works quite well in most cases.
On 10 Feb 2009, at 09:55, Peter Saint-Andre wrote:
At the XMPP Summit yesterday, we talked about a few items of
interest to
BOSH implementors:
1. Nathan Fritz raised the issue of session collisions, which they've
seen at Seesmic. As far as I know, no conclusions were reached on this
issue. Feel free to expland on this if you were part of the
discussions.
2. Consensus that the current secure="true" flag on the BOSH <body/>
element is useless. Jack Moffitt recommended removing this and
adding a
security consideration about what the BOSH connection manager should
accept and not accept from the XMPP server. He and I will work on
text.
3. In a hallway discussion at 2 AM one morning, Fabio Forno
mentioned to
me that the spec might explicitly say that a BOSH connection manager
could support HTTP cookies as an optimization (support would be
completely optional). I don't know if he brought this up during the
meetings because I was roving around from group to group.
4. I mentioned that writing the BOSH section of the XMPP book had
helped
me grok BOSH in fullness, so I may adjust the spec to reflect that new
understanding.
What am I missing?
/psa
[ written en route from Brussels, delivery times may vary :) ]
Artur
--
Artur Hefczyc
http://www.tigase.org/
http://artur.hefczyc.net/
