General Questions about TIMP

Is TIMP compatible with other XMPP Servers and Clients?

Tipic Instant Messaging Server and ATEClient(the client SW Component) are XMPP compatible.

(TIMP is based on the Open Source JSM - Jabber Session Management)

You can use any XMPP Client with Tipic Instant Messaging Server.

How does TIMP compare with Jabber Inc. Commercial Server?

There have been no comparisons made between the j.o server and Tipic's; the reality is that it would be like comparing apples and oranges because of the underlining OS. The two servers may well coexist because of the two OSs.

Do I buy one server or different servers for different branches?

XMPP is just like e-mail. You can have different "branches" with different domain names chatting; as an example:

branch1 is one location with one server; users can chat between each other
user1@branch1.com
user2@branch1.com
user3@branch1.com
user4@branch1.com
.....

branch2 is another location with one server; users can chat between each other
user1@branch2.com
user2@branch2.com
user3@branch2.com
user4@branch2.com
.....

when user1@branch1.com chats with user2@branch1.com their chat is Client-Server-Client

when user1@branch1.com chats with user1@branch2.com their chat is Client-Server-Server-Client

Now with Jabber like with e-mail you can decide to have a server for each "branch"; the advantage is scalability and the fact that if an internet connection goes down, users of one server can still chat between each other.

What is ATE?

ATE is the the XML Router, which is the core of Tipic Instant Messaging Server. Plug-Ins are linked to ATE, through ATEConsole, and receive/elaborate/reply XML messages. Also the Instant Messaging functions are carried out by a Plug-In called JSM, which is the perform the Instant Messaging logic and is the Open Source component.

How does TIMP scale?

There are two possible ways to scale a Jabber Server (and thus TIMP):
-- e-mail like, appropriate for Corporations (Enterprise): if your Company is divided in different departments or countries, you can have a Jabber server for each of those (like e-mail - xxx@yyy.zzz.com aaa@mmmm.zzz.com); the users of these servers see each other through s2s connection.
-- ISP like environment: you have one domain and want to scale the number of users on that domain.
the approach here is that of server farming, which TIMP does nicely - each server can have around 1,000 or more concurrent users (due to windows limitation on sockets), and you can farm together the servers. From our experience, in an ISP environment, you have a ratio of less than 1/10 (concurrent users/ registered users), which means that each server can manage 10,000 or more registered users!

How heavy is TIMP in terms of CPU load ?

The CPU load does not depends on the number of client but on the number of messages routed.

Usually, also the roster size affects performance. At tipic.com we run TIMP with a mean many hundreds concurrent users in busy hours so DEFINITELY the problem is not in the number of connected clients.

TIMP uses a kind of "traffic shaping" to limit the number of messages per second a client can send; if a client exceeds that limit it happens to be "karmed" in the O.S. version of jabber (which lead to
messages lost) or simply disconnected in TIMP.

If you have developed a server side plug-in plug-in you have to check if you are sending too many messages; in this case the client gets disconnected and then it sudden reconnects in a neverending loop which in fact might lead to 100% CPU usage.

You can easly check the number of messages that are circulating in the system either by using TIMP console / Server log (remember to press on the "Update Log" button) or just looking in the text file "C:Documents and settingsTW32JS_USERApplication DataTipicMainAte.log" where you can find some rows like "Router: xxx messages successiful routed". The server writes such a line about every 30 seconds, so subtracting the value found in the last two entries you get half the messages per minute TIMP is routing.

Another cause of 100 CPU would be a kind of Misconfiguration in which TIMP sends a message to the s2s component and this then re-send it back to TIMP in a neverending loop.