The librarians' webchat client disconnects

Note: The webchat client may not operate reliably if Real Player is installed. Check for Real Player before looking into anything more complex.

The librarians' webchat client does not have any automatic time-outs. However, there are a few circumstances that will cause it to disconnect and return the user to the login page.

Whenever the webchat detects that it has been disconnected, it begins attempting to reconnect. While it is trying to reconnect, it sets your status to unavailable, and it returns your status to available when you are connected again. If it is unable to reconnect within 5 minutes, it gives up and re-displays the login.

Causes of webchat disconnects:

• Poor network conditions. Examples: dropped packets, low connectivity over wireless, and upstream problems.
• Signing into the same account from a second location (or a different browser on the same computer).
• Signing into the admin site in the same browser as a different user.
• Doing test chats from the same browser on the same computer. This works in some browsers (Firefox 3) but not others (IE6 and 7).
• Computers going to sleep because of idle time. Because of browser sandboxing, this problem may manifest as the webchat client appearing to be signed in when it really is not. The computer's idle process will not always communicate the closed state of the connection back to the browser.
• Switching between networks while signed in. Example: taking a laptop out of its dock to switch from a wired to a wireless network. You must sign out and back in when changing networks.
• Proxy servers. A proxy server will even drop a connection in the middle of active chats. They have several problems:
  1. They don't respect the long-running connections to the libraryh3lp server, causing the disconnects.
  2. They cache responses, which interferes with the reconnection attempts.
  3. Depending on configuration, they may also limit the number of simultaneous connections to any particular host across the network. This may cause problem to appear only once a particular critical mass of people is signed in and/or chatting all at once, as can happen when bringing a service up live, following a successful testing period with fewer numbers of simultaneous logins.
  Note that we are NOT concerned with proxy servers such as EZProxy. That is a different animal and works fine with LibraryH3lp. We are concerned with proxy servers used internally, often to boost performance on large networks.

Suggestions for users of proxy servers:

The proxy server problem often can be solved completely by increasing proxy read timeout and/or increasing the number of allowed connections to a site. However, this requires that the person in charge of running the proxy server will actually make the change. :-)

You can also try using the secure port (https): https://libraryh3lp.com/webchat

The proxy server may not cache https connections as aggressively as http connections.

Try Meebo...

If you need to use a web-based client and have disconnect problems with the native LibraryH3lp client, try Meebo.com. Meebo uses fundamentally different technologies to maintain the connection, and their way may work better in your network environment. The downside is that when answering chats from Meebo, you will have to sign into libraryh3lp.com to do specialized LibraryH3lp things such as transfer and send files.

You do not need a separate Meebo account to sign in with your libraryh3lp account! However, there is no harm in using a Meebo account, and then adding your LibraryH3lp account to it, if you prefer to do so.

To sign into Meebo directly with your LibraryH3lp account, look for the Jabber option, with the lightbulb logo, on their main page. Then sign in as username@libraryh3lp.com with your usual operator password.

Locally-installed clients are more robust

Despite all our efforts to make the webchat client as reliable as possible, it will not work well for everyone. Locally-installed clients (those installed directly on a computer rather than only running through the web browser) will always be more robust than a web client. You may have to use one of these.