When you think ASP, think...
Recent Articles
All Articles
ASP.NET Articles
ASPFAQs.com
Message Board
Related Web Technologies
User Tips!
Coding Tips

Sections:
Sample Chapters
Commonly Asked Message Board Questions
JavaScript Tutorials
MSDN Communities Hub
Official Docs
Security
Stump the SQL Guru!
XML Info
Information:
Feedback
Author an Article
ASP ASP.NET ASP FAQs Message Board Feedback
Print this page.
Published: Monday, April 10, 2000

ASP Instant Messaging

By 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.

- continued -

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.

  • Read Part 2


  • ASP.NET [1.x] [2.0] | ASPMessageboard.com | ASPFAQs.com | Advertise | Feedback | Author an Article