Introduction:
In its new avatar, ASP has undergone a metamorphosis. It is no longer confined to simple server-side scripting. It is no more mere bits of HTML contents or data inserted into template HTML code. With it, you can create a full-fledged web application, on the fly, with control over several critical factors.

Anyway, you may ask, what is the difference between a web application and a web page? In server side scripting your role is limited to, and ends with, the rendering of the web page on the client's browser, save that, you can maintain some control over the session and session related variables. On the other hand, for a web application, you approach the whole affair differently - the server is where the action takes place and the page is no longer a simple HTML document. Instead, the web page is a frame on which you create an interactive session between you and the client or between clients among themselves. You compose it from scratch placing elements at the appropriate places, wiring up event handling, storing variables not only for the session state but also for the application state and most importantly controlling flow of information between client and server and from client to client.

The last mentioned ability makes an ASP.NET application into a Peer 2 Peer Networked Application. This article will present you with one such Peer 2 Peer networked application in the form of a Chat application.

Charting the course for chatting
How do you create a Chat Application? Traditionally, for a chat application, you have to create aserver side listener, which requires a server side TCP/IP channel and listens for requests from clients. These requests can be of two types:

Registering a new chat participant
Passing on chat messages to other chat participants.
In addition, the server-side program gets a handle to the client object and uses this handle to update chat messages of the participants as well as the list of participants at any given time.

However, in this ASP.NET application, the problem of the Server-side listener can be side stepped, as ASP.NET itself will be the listener. Thus there is no hogging of a TCP/IP channel for a dedicated listener.Since an ASP.NET Application uses the HTTP Protocol and the corresponding Port 80, it is not affected by most of the firewalls, unlike a dedicated chat listener. TheHttpApplicationState State Object, provided to us by the NET Framework, solves the problem of sharing information across applications. The options available to us in this regard are:

TheHttpApplicationState Object,
The System.Web.Caching.Cache object,
Database back end
The Isolated Storage Dump.
Whilst the last two options involve Read/Write/IO operations, they are not suitable for a simple chat application where the speed is the essence and there is no great amount of memory involved. The cache object does not provide for locking and may affect synchronization when several users access the page at the same time. Hence, we zero in on theHttpApplicationState object for our data storage. Finally we handle the trickiest question of pushing messages from the server to the client using the web services behavior of Internet Explorer 5.0 and above

There is also no need for support staff starting or ending an application.ASP.NET acts as the master application and is expected to keep going as long as the IIS is running on the Server.

Thus, we can summarize our course of action as follows:

Design aChatMessage Object and create a placeholder for these objects at the Application Level. (Why do we do this at the Application' Level? - ASP.NET enables us to keep variables at the Application level as well as at the Session level. However, the session level variables cannot be shared between sessions unlike the Application level variables. Therefore, we pitch for the Application variables