Thursday 10 September 2009

Trillian Automation + Too much time on my hands...

Preface
While the majority of my friends and colleagues have reasonably reliable internet, there are a few that, for whatever reason, have a hard time maintaining their connections. While most of them know that their connections are unreliable at best (either due to their ISP, bandwidth usage, equipment failure or that they are wardriving) a few have no idea that their connections are stuttering.


A connection is said to be stuttering when the connection drops but for such a short period that, based on how they use their connection, there is no glaring indication of what just happened (I imagine most users don't run perpetual ping-tests). Microsoft's 'Live Messenger' (and the various other chatting services) is a major culprit here - particularly so with the advent of offline messaging.

MSN (and other chatting services) operate by having a user sign on. This sets the client's state as being 'connected' (this is independant from the user's actual status i.e., available, away, invisible etc). The client checks back with this central messaging server every so often to make sure that the user is still connected. With the official MSN client, (empirically), it looks like this check is made every eight seconds or so. This is just when the client is sitting there, doing nothing. During active conversations, I would estimate the check to be four seconds or so.

When the client software [successfully] checks in with the central server, the software is "reassured" that it is still connected. The software (and thus, the user) is only made aware of  a problem in the event that this check fails. What this means, is that if the user's connection drops and is subsequently restored during the 7.9 seconds window between checks (3.9 seconds for active chats), the user has no idea that they were, in fact, offline for a very small window. From the end user's (the one with the dodgy connection), there is no reason to care -- they aren't aware of the disconnect and thanks to the luxury of offline messages, most of the time, they don't miss anything from the conversation.

It is important to note that offline messaging is not bullet proof. I don't quite know how the various offline messaging system work but I from time to time, we've all recieved the "such and such message failed to be delivered" error message even when both users in the conversation might be using client software that supports offline messaging.


Tracking it down...
The first step to fixing anything is to first be aware of the problem. This is where Trillian Astra's powerful automation functionality comes in. Trillian has always had the ability to perform automated, event triggered actions (such as messaging you when so and so signed online). Aftermarket extensions such as Messenger Plus! have similar capabilities but they are extensions of MSN meaning they too have 3.9/7.9 second potential gaps in connectivity.

Trillian, as far as I can tell, has a refresh time of about one second regardless of whether an active conversation is in progress or not. Also being a single automation platform for the various different chat protocols allows it to be a fantastic.


Trillian User Tracker
Sounds creepy. But you haven't seen anything yet. Evidently, I was bored. Check it out this little application (I'll abbreviate it as TS for Trillian Stats).


So yeah.... trendbuilder! Keeps track of all the sign-on/sign-off as well as a stats breakdown of online time and access to the individual's contact log. So yeah, creepy as this is, it allows for tracking down how often the user is able to sustain connectivity without having automated on-contact messages. Also allows for them to track down exactly when they lost connectivity (often it's an issue with the router/wireless). So yeah, this allows for  keeping track of the uptime/downtime stats over time for trend-building (i.e., time of day trends for disconnects).

As for actually automating this, Trillian automatically handles the linking: fires up the application whenever designated users are detected as being signing on or off. Naturally there is not distinction between 'invisible' and 'signing off'.


Extending this...
Now thanks to the awesomeness that is Trillian Automation, there's so much more that can be done ... all sorts of tomfoolery in fact.
  • Trillian has the 'heads-up' function: I get a heads up approximately one second before and incoming message (i.e., I get the "Jon Smith is typing a message" alert before the user finishes sending the message). This allows for automated preemptive messages: "I see you" or "Type faster"
  • Now you can also set your status message to "John Smith is a douche" -- until John Smith begins to send a message at which point you reset it :P
  • Not just tracking the online statistics but you can track the response time of users (i.e., how long it takes users to chat, the average length of individual chats, whather or not the user tends to send single long messages or multiple short bursts, whether or not the user tends to leave abruptly etc). Now this, by itself, is just an interesting exercise in statistics, but then you can merge this with automation and you can start classifying chats based on responsiveness (and thus raise/lower chat priorities). Pretty neat (yet useless) stuff once you start messing with it.


Yup. Too much time.

2 comments:

  1. Do you have that Trillian Stats as an available program?

    ReplyDelete
  2. Um yeah I guess... code needs a clean up, I'll clean it up over the next few days and post it if you're still interested.

    ReplyDelete