powered by Jive Software

Transfer files and MUC over an intranet

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):

  1. JEP-0065 SOCK5 Bytestreams (prefered method)

  2. JEP-0047 In-Band Bytestream (desirable for simple bytestreams)

  3. JEP-0066 Out of Band Data (old method replaced by the above)

and

  1. JEP-0096: File Transfer (used for negotiating the preferred method)

About server support:

  1. 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.

  2. JEP-0047: Server support is required but you may use it even though the server does not implement its part.

  3. JEP-0066: No server support is required.

  4. JEP-0096: No server support is required.

Regards,

– Gato