Hello,
Yesterday we setup Jive Messenger 1.1 on our MacOS X 10.2.8 machine and used the IP as the Server/Chat/MUC name. We were able to connect with PSI and GAIM on Windows, IM and File Transfer worked but we couldn’‘t setup a MUC. Wasn’'t a big deal, we really just wanted 1 on 1 IM and File Transfer.
Today we wanted to change from the IP to the server’‘s local domain name, we did so and made the nessecarry updates to the clients so they would connect and users would show up online. Now we can IM, still can’‘t use MUC, and now we can’‘t transfer files, better yet, we changed it back to the original configuration and still can’'t transfer files.
We are using the Berkley DB backend, but other wise we are running on the default settings. Any idea what the problem might be?
Thanks
JKritner,
Could you post the Server/Chat/MUC names that you are currently using? Remember that your domain name changes will only take effect after you reboot the server. Regarding the MUC problem, could you post the XMLs that the client is sending and receiving?
BTW, I’‘d recommend using the server’'s local domain name instead of its IP address.
Thanks,
– Gato
We are using macfileserver as the name for all three (yeah we are really creative )
When I try to create a new chat room my client sends the following:
0
and nothing is recieved back.(clients just sit there waiting until I cancel)
Also in case it helps with file transfer, I captured the XML from a file transfer, one on the sending side and the other on the recieving side. In both cases they connect and the sender can send the request to the reciever, but even if the reciever accepts, the sender seems to be denied.
http://jabber.org/protocol/bytestreams
http://jabber.org/protocol/bytestreams
Could not connect to given hosts
http://jabber.org/protocol/bytestreams
http://jabber.org/protocol/bytestreams
And here is my jive-messenger.xml for reference:
MacFileserver
MacFileserver
number
MacFileserver
number
1
2
3
4
false
false
false
false
false
true
5222
true
5223
JKS
security/keystore
changeit
false
store
0
true
45000
0
9090
com.jivesoftware.chat.database.HSQLConnectionProvider< /className>
0ECoB58mLvIzXKV
true
false
Thanks for Any help you can provide
JKritner,
The domain names of the server, the chat service and the Multi-User Chat service MUST be different. Otherwise, you will have routing problems.
Standard names could be for:
domain = MacFileserver
chat = chat.MacFileserver
muc = conference.MacFileserver
The error codes that your clients were receiving were originated by the other client and not by the server. Let’'s first change the domain names and then check if you are still having problems.
Regards,
– Gato
Okie doke, changed to the recommended names, restarted and I think we are getting somewhere.
chat.macfileserver works for groupchats, we can join, invite and converse without a problem. (this is a BIG help and covers almost everything we wanted from a groupchat session)
conference.macfileserver has some issues, I can create and configure a room with GAIM(or at least it makes me think I am creating a room…), but no one can connect to it once the room is created. If I try to create or join a room in any other client, I get an unspecified error:
0
0
And when I close the room in GAIM the client gets booted from the server and I have to log back on.
This problem isn’‘t a big deal though, we really don’'t need moderated and persistent chat rooms for an office with 8 people
The file transfer problem remains though
Thanks for the help provided so far.
Good to hear that things are better now. Regarding the Multi-User Chat problem the most probable cause is that the room is still locked. If a room is locked and a client that doesn’'t support MUC tries to join a room a 400 error code (bad_request) is returned. OTOH, if a user which is not the room owner and supports MUC tries to join a locked room, the user will receive a 404 error code.
You need to configure the room so that it will be available for other users to join.
Let me know if that helps.
Regards,
– Gato
Alright, I found a client that seems to support MUC -and- has an easily accessable XML debug window…
it seems to show that the room is unlocked.
SENT: Available0
RECV:
RECV: jkritner has joined the roomThis room is locked from entry until configuration is confirmed.
SENT:
RECV: Configuration confirmed: This room is now unlocked.
RECV:
I stll get the same response as the previous post when another user tries to connect, It just sorta stays in a wait-state until I cancel the connection process (it never even times out, I left it for nearly 15 minutes at one point).
Thanks for the help so far
Yup. Exodus is a good client that supports MUC although the latest release has some bugs when an admin tries to configure the room (it uses the wrong namespace).
I stll get the same response as the previous post
when another user tries to connect, It just sorta
stays in a wait-state until I cancel the connection
process (it never even times out, I left it for
nearly 15 minutes at one point).
Are you having the same problem? In your previous post you said that a 400 error code was returned and in this post you are referring to an infinite wait. I see now that the room is unlocked. Could you post the XMLs sent and received by the other clients that are trying to join the room?
Thanks,
– Gato
It seems to be a Client issue, we got a couple of machines setup with Exodus and MUC seems to work fine with them, all other clients(that even pretend to support MUC) that we have tried get this when they try to connect:
0
they never recieve any kind of response from the server.
I think at this point my concern is primarily with file transfer, I have tried nearly every combo of sender and recipient clients that I can think of and they all come up with the same back and forth XML as I posted earlier
Sender initiates transfer, reciever is prompted to accept and save the file, recipient gets some variation of “Unable to Connect” and the sender gets “File Transfer Denied”
here is the log from the two exodus clients
dgriffith is sending to jkritner:
RECV:
RECV:
SENT:
RECV: http://jabber.org/protocol/bytestreams
RECV:
SENT: http://jabber.org/protocol/bytestreams
RECV:
RECV:
SENT: </erro r>
I can’‘t think of anything network related that would cause the two clients to not be able to see each other, I have disabled the software firewalls on each just to make sure, and the router shouldn’'t be blocking any internal traffic…
If you or anyone have any ideas, they will be very much appreciated.
Thanks
The Messenger version that you are using does not support a client that doesn’'t support MUC to join a MUC room. That problem has been solved. The fix will be available in the next version which is going to come out soon.
Regarding the transfer problem I have to take a deeper look at the problem to give you my comprehension of the problem.
Thanks,
– Gato
I am having a problem setting up File Transfers on Jive Messenger 2.0.1. Reading this thread got me to thinking about adding a different hostname for file transfers. There is not an interface to do this in the admin webGUI, so would I add the setting as a system property?
Hey Jonathan,
Which method of File Transfer do you want to use? XMPP defines 3 different methods which you may use. Depending on the transfer method you may need server support or not.
Available methods are (in order of preference):
-
JEP-0065 SOCK5 Bytestreams (prefered method)
-
JEP-0047 In-Band Bytestream (desirable for simple bytestreams)
-
JEP-0066 Out of Band Data (old method replaced by the above)
and
- JEP-0096: File Transfer (used for negotiating the preferred method)
About server support:
-
JEP-0065: No server support is required if the socket is direct (i.e. peer-to-peer). But if you need to establish the connection through a bytestreaming service then server support is required. Messenger does not have support for “Mediated Connections” so you can only use the peer-to-peer mode.
-
JEP-0047: Server support is required but you may use it even though the server does not implement its part.
-
JEP-0066: No server support is required.
-
JEP-0096: No server support is required.
Regards,
– Gato