New Media Specialist Aquent US-CO-Denver Post A Job | Post A Resume

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 Global.asa)

<script language="VBScript" runat="Server"> Const adInteger = 3 Const adVarChar = 200 Const adDate = 7 Const adDBTimeStamp = 135 Const adChar = 129 Const adLockBachOptimistic = 4 Const adUseClient = 3 Sub Application_OnStart aChatDB.CursorLocation = adUseClient aChatDB.LockType = adLockBatchOptimistic aChatDB.Fields.Append "toID", adChar, 50 aChatDB.Fields.Append "toName", adChar, 50 aChatDB.Fields.Append "fromID", adChar, 50 aChatDB.Fields.Append "fromName", adVarChar, 50 aChatDB.Fields.Append "TimeSent", adDBTimeStamp aChatDB.Fields.Append "Message", adChar, 65534 aChatDB.Open End Sub Sub Session_OnStart cChatDB.Fields.Append "toID", adChar, 50 cChatDB.Fields.Append "toName", adChar, 50 cChatDB.Fields.Append "fromID", adChar, 50 cChatDB.Fields.Append "fromName", adVarChar, 50 cChatDB.Fields.Append "TimeSent", adDBTimeStamp cChatDB.Fields.Append "Message", adChar, 65534 cChatDB.Open End Sub </script> <object runat=server scope=application id=aChatDB progID="ADODB.Recordset"></object> <object runat=server scope=session id=cChatDB progID="ADODB.Recordset"></object>

If you notice, cChatDB and 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.

Jupitermedia Corporation has two divisions: Jupiterimages and JupiterOnlineMedia

Jupitermedia Corporate Info

Legal Notices, Licensing, Reprints, Permissions, Privacy Policy.
Advertise | Newsletters | Tech Jobs | Shopping | E-mail Offers