Hey ejabberds,
i try to run jwchat or muckl with ejabberd's http binding since a year or two now. This week i tried it on a new server with the current ejabberd 2.0 and the current JSJac 1.3. If one or two users are connected to the same /http-bind/-interface and the same ejabberd, everything will run fine and there will be no problems. Beautiful.
So i put a muckl conference room chat online where every user connects through the same binding or polling interface to the same chat. But after several people had joined the chat, who are sending messages to the chat room in a more or less speedy way, people got randomly disconnected again, including me, who was not writing anything. Sometimes the user just gets disconnected, other times ejabberds http-bind-interface returns a 503 error which results in a disconnect. Yesterday I had some time to turn on the debugging log in ejabberd and play around with 8 to 10 concurrently connected users. And finally I've found the place where things go wrong - independent of the fact, whether http-bind or http-poll is used:
=INFO REPORT==== 2008-04-04 23:08:42 ===
D(<0.776.0>:ejabberd_http_bind:378) : Key/OldKey/NextKey: 17b56013a1cdc083be77bf3666a2304cebe8cc89/7a8021615404a5127293a117571b5982ce593b74/
6e2fedd7c418fd99d02d368e29a6703bf0ea00d7
=INFO REPORT==== 2008-04-04 23:08:42 ===
D(<0.776.0>:ejabberd_http_bind:384) : wrong key: 17b56013a1cdc083be77bf3666a2304cebe8cc89
=INFO REPORT==== 2008-04-04 23:08:42 ===
D(<0.776.0>:ejabberd_http_bind:663) : terminate: deleting session c44f142bba6786c1f574d836ab9abc2b144c2adf
I don't know how this key system works. So I don't know if it's maybe a timing problem in the client or a general problem with the http-bind/poll interface. That's why i'm writing here ;) I hope you have an idea.
If you need additional information, please ask. Thanks for your support.
cheers,
flip
btw, it would be useful, if
btw, it would be useful, if the "wrong key" or "deleting session" message is also displayed in the standard log.
a client supporting http binding?
i'd like to test another client with http binding. not a jsjac-based client.
i remember a windows or java client supporting binding-connections.
does anyone know which client this is?
No idea. Maybe ask in jdev chatroom / mailing list
i'd like to test another client with http binding. not a jsjac-based client.
i remember a windows or java client supporting binding-connections.
does anyone know which client this is?
HTTP-Bind is rarely implemented, I only know of JWChat and MUCkl. If another client implements it, I guess it must be a well established client.
Regarding Java, it could be Jeti or Spark, but none of them is advertized as supporting HTTP-Bind. Specific Windows clients, I think none is still in development. Cross-platform clients that run on Windows don't implement it (Psi, Gajim, Tkabber, Coccinella).
You can ask in the jdev chatroom (jdev@conference.jabber.org ) or in the JDEV mailing list in www.jabber.org
Sorry, I also meant clients
Sorry, I also meant clients supporting HTTP-polling. The problems occur with HTTP-binding and HTTP-polling, so at this moment I don't care which method I'll test. I've found Exodus (crashes with use of proxy and HTTP-poll) and Psi. Psi runs fine with HTTP-polling, so I'll use it for my tests. Tomorrow I'll report whether the "key problems" also occur with Psi's HTTP-polling or not.
HTTP-Polling with ejabberd works fine
I've just tested Psi with 8 HTTP-Polling conference room participants over the same polling interface and a lot of text ;) Everything works fine. So this key or connection problem seems to be a bug in MUCKl or JSJac. In the next step I'll test the current JWChat using the current JSJac. Maybe it's just a problem of MUCKl. I hope so :)
cheers,
flip
JSJaC bug
Testing done. JWChat has the same problems :(. So it seems to be a JSJaC bug. I'll report it to the developer.
binding problems
I may have jumped the gun there. I've simply forgotten the cache ;) HTTP-Polling with JSJaC has no session key problems, only HTTP-Binding. I have no idea whether it's a ejabberd or a JSJaC problem because there's no other client for me to test it.
bosh
I've found another javascript library supporting BOSH. It successfully connects to tigase (another jabber server supporting BOSH) but unfortunately not to ejabberd.
connection to ejabberd using BOSH:
[2] Succesfully connected to localhost
[2] creating session with id GjP4lGrxCd56SNMaOcOoRcOK
[2] inQueue: <?xml version='1.0'?><stream:stream xmlns='jabber:client' xmlns:str
eam='http://etherx.jabber.org/streams' id='2046858242' from='localhost' version=
'1.0' xml:lang='en'><stream:features><mechanisms xmlns='urn:ietf:params:xml:ns:x
mpp-sasl'><mechanism>DIGEST-MD5</mechanism><mechanism>PLAIN</mechanism></mechani
sms><register xmlns='http://jabber.org/features/iq-register'/></stream:features>
[2] inQueue: <stream:features><mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sas
l'><mechanism>DIGEST-MD5</mechanism><mechanism>PLAIN</mechanism></mechanisms><re
gister xmlns='http://jabber.org/features/iq-register'/></stream:features>
[2] sending response [7357]: <body xmlns="http://jabber.org/protocol/httpbind" x
mlns:stream="http://etherx.jabber.org/streams" authid="2046858242" inactivity="6
0" polling="2" requests="2" sid="GjP4lGrxCd56SNMaOcOoRcOK" wait="60"><stream:fea
tures><mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl"><mechanism>DIGEST-MD5
</mechanism><mechanism>PLAIN</mechanism></mechanisms><register xmlns="http://jab
ber.org/features/iq-register"/></stream:features></body>
[2] inQueue: <iq from='localhost' id='id0.7795918087111591' type='error'><error
code='503' type='cancel'><service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp
-stanzas'/></error></iq>
[2] sending response [7358]: <body xmlns="http://jabber.org/protocol/httpbind"><
iq xmlns="jabber:client" from="localhost" id="id0.7795918087111591" type="error"
><error code="503" type="cancel"><service-unavailable xmlns="urn:ietf:params:xml
:ns:xmpp-stanzas"/></error></iq></body>
connection to tigase using BOSH:
[2] Succesfully connected to localhost
[2] creating session with id 010pmgY_kSulRJq0EyxMtKdY
[2] inQueue: <stream:stream version='1.0' xml:lang='en' from='localhost' id='955
fc030-148d-4418-a8ae-054076dced24' xmlns='jabber:client' xmlns:stream='http://et
herx.jabber.org/streams'>
[2] failed to get stream features
[2] inQueue: <stream:stream version='1.0' xml:lang='en' from='localhost' id='955
fc030-148d-4418-a8ae-054076dced24' xmlns='jabber:client' xmlns:stream='http://et
herx.jabber.org/streams'><stream:features><auth xmlns="http://jabber.org/feature
s/iq-auth"/><register xmlns="http://jabber.org/features/iq-register"/><starttls
xmlns="urn:ietf:params:xml:ns:xmpp-tls"/><mechanisms xmlns="urn:ietf:params:xml:
ns:xmpp-sasl"><mechanism>PLAIN</mechanism><mechanism>DIGEST-MD5</mechanism><mech
anism>CRAM-MD5</mechanism></mechanisms><session xmlns="urn:ietf:params:xml:ns:xm
pp-session"/></stream:features>
[2] inQueue: <stream:features><auth xmlns="http://jabber.org/features/iq-auth"/>
<register xmlns="http://jabber.org/features/iq-register"/><starttls xmlns="urn:i
etf:params:xml:ns:xmpp-tls"/><mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl
"><mechanism>PLAIN</mechanism><mechanism>DIGEST-MD5</mechanism><mechanism>CRAM-M
D5</mechanism></mechanisms><session xmlns="urn:ietf:params:xml:ns:xmpp-session"/
></stream:features>
[2] starttls present, trying to use it
[2] <proceed xmlns="urn:ietf:params:xml:ns:xmpp-tls"/>
[0] initiating handshake
[2] tls failed but we don't need to be secure
[1] socket closed
[2] inQueue: <stream:stream version='1.0' xml:lang='en' from='localhost' id='5a3
c0079-6d83-495d-8baa-32351cd1d3c1' xmlns='jabber:client' xmlns:stream='http://et
herx.jabber.org/streams'>
[2] failed to get stream features
[2] inQueue: <stream:stream version='1.0' xml:lang='en' from='localhost' id='5a3
c0079-6d83-495d-8baa-32351cd1d3c1' xmlns='jabber:client' xmlns:stream='http://et
herx.jabber.org/streams'><stream:features><auth xmlns="http://jabber.org/feature
s/iq-auth"/><register xmlns="http://jabber.org/features/iq-register"/><starttls
xmlns="urn:ietf:params:xml:ns:xmpp-tls"/><mechanisms xmlns="urn:ietf:params:xml:
ns:xmpp-sasl"><mechanism>PLAIN</mechanism><mechanism>DIGEST-MD5</mechanism><mech
anism>CRAM-MD5</mechanism></mechanisms><session xmlns="urn:ietf:params:xml:ns:xm
pp-session"/></stream:features>
[2] inQueue: <stream:features><auth xmlns="http://jabber.org/features/iq-auth"/>
<register xmlns="http://jabber.org/features/iq-register"/><starttls xmlns="urn:i
etf:params:xml:ns:xmpp-tls"/><mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl
"><mechanism>PLAIN</mechanism><mechanism>DIGEST-MD5</mechanism><mechanism>CRAM-M
D5</mechanism></mechanisms><session xmlns="urn:ietf:params:xml:ns:xmpp-session"/
></stream:features>
[2] sending response [1427]: <body xmlns="http://jabber.org/protocol/httpbind" x
mlns:stream="http://etherx.jabber.org/streams" authid="5a3c0079-6d83-495d-8baa-3
2351cd1d3c1" inactivity="60" polling="2" requests="2" sid="010pmgY_kSulRJq0EyxMt
KdY" wait="60"><stream:features><auth xmlns="http://jabber.org/features/iq-auth"
/><register xmlns="http://jabber.org/features/iq-register"/><mechanisms xmlns="u
rn:ietf:params:xml:ns:xmpp-sasl"><mechanism>PLAIN</mechanism><mechanism>DIGEST-M
D5</mechanism><mechanism>CRAM-MD5</mechanism></mechanisms><session xmlns="urn:ie
tf:params:xml:ns:xmpp-session"/></stream:features></body>
[2] inQueue: <iq id="id0.3616666284653558" from="localhost" type="result">Authen
tication successful.</iq>
[2] sending response [1428]: <body xmlns="http://jabber.org/protocol/httpbind"><
iq xmlns="jabber:client" from="localhost" id="id0.3616666284653558" type="result
">Authentication successful.</iq></body>
How to reproduce
I've found another javascript library supporting BOSH. It successfully connects to tigase (another jabber server supporting BOSH) but unfortunately not to ejabberd.
If you consider this a bug in ejabberd, you may want to provide information so it can be properly reported as a bug in the bug tracker:
The purpose is to reproduce the problem in the laboratory, so it can be carefully inspected.