ASP Instant MessagingBy Ryan S.
In my previous article on Instant Messaging, I discussed a highly crude way to message clients over an HTTP connection. In development for a pet project of mine, which was highly dependent on ASP, I came to the conclusion that I needed to develop some way for my site visitors to communicate effectively across my site. I thus came up with a method, which makes utilization of Session and Application variables, and no physical binding to any database server. As an extra perk, the Session variables keep the Application variable from becoming too large, allowing for effective communication.
Realize that this is not intended to be a corporate scale application, as it was written with low usage (tops, 100 users, at the very top) in mind, and thus that's why I opted to use Session/Application variables.
The method I opted to use to enhance the scalability was to use custom recordsets, allowing much more functionality than arrays as well as the ability to quickly filter. (To learn more about custom recordsets, be sure to read my earlier article, Using Custom Recordsets.) I use an application variable to act as the middle-tier object between two clients attempting to communicate, and two session variables, one on each of the clients computers, to maintain the users copy of the session. Because of this, I have my session timeout extremely low, specifically at five minutes, so that it can get cleaned up quickly.
So, with that said, let's get to the nitty gritty code. The first part, and
crucial for the set up of the chat application, is that we establish the
objects in our
Global.asa, and instantiate the proper methods. Here's what I
used (actually, this is merely an excerpt from my production level
If you notice,
aChatDB are the exact same in
structure, but one
rests on the client, and the other rests on the server. The reason is to
keep the overall size of the application wide variable down, because clients
will be attempting to access it and perform queries, so smaller is faster.
Now, I understand the obvious apprehension a good ASP programmer should be feeling about sticking ADODB objects into the Session and Application variables, because they can hog memory. Then again, a good ASP programmer could write himself an object that utilizes Windows Sockets and instantiates itself into an endless loop, failing to end the HTTP stream, and writing out a serious of scripting methods which update the user in a truly real time solution. This is intended as a rough outline for possible methods, and like I said, this isn't intended for production level environments where the scalability is a concern or reliability is a strong issue. This works great for personal sites, and makes great bragging rights in the ASP community, however =)
Next, we will write our code that can send a message, retrieve a message, and output the messages to the user's screen. I opted for a frames based approach, instantiating a 250 x 300 window, and three frames, the top displaying who the user was talking to, the mid frame containing the body of the chat, and then the bottom frame containing the instruments for communicating.
Features I plan on working are such as sound, etc. Also, a feature I did put into work but do not discuss, as it is outside the true content of this article, is having the window automatically spawn and display the chat, if a user sends a message to someone.
Also, I assume some very basic things in this. That every user has a unique ID, and a unique name. An option, for the truly studious programmer, is to write a COM+ application that utilizes no properties but offers the same functionality, by maintaing COM+ objects that pass along IDs as function calls. Tricky, but I'm sure it can be done =)
In Part 2 we'll look at code needed on the client to handle our communications between users.