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 aserver 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. TheHttpApplicationState 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:

TheHttpApplicationState 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 theHttpApplicationState 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 aChatMessage 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.)
Create a web service which provides three methods - one for registering a participant, one for exchanging messages with him and one for merely supplying the waiting messages at the askance!
Design a client web page that uses DHTML Behavior known as webservice behavior given to us by Microsoft as webservice.htc.
Componentise the client side code - so that web developers need not know the intricacies of using Web Services, XML, XMLHttp and DHTML Behaviors, in order to use the application we made.
Creating the webservice:
As mentioned earlier, in a Peer to Peer application, the server support is needed for three actions - registering the peers, receiving messages for routing and passing on waiting messages. Therefore, our web service will have three Web Methods:

public string RegisterMember(String NickName)
public ChatMessage XchangeMsgs(String NickName, String Msg)
public ChatMessage GetMsgs(String NickName)
The web service is encapsulated in a class called ChatWebService, which is derived from System.Web.Servicesand is contained in the source code fileChatWebService.cs in the namespace PrasadWeb. The namespace also defines two other classes calledMember and ChatMessage. The classMessage has a string variable called UserName, a DateTime variable calledLastAccessTime and a public property NickName, which gets and sets the variableUserName together with the time of his registration. The ClassChatMessage has merely two string variables calledUserList and Messages. These two variables hold formatted lists of Chat Participants and the undelivered chat messages at any given time.

The main classChatWebService has two private methodsString GetMemberList() and Void CheckMemberList(), besides the three Web Methods mentioned earlier. The former function returns the list of chat participants at any given time as a formatted list. The later function checks to see if any chat client has been absent from the circuit for more than 2 minutes and removes him from the chat list, so as to keep the environment free from quitters. TheGetMemberList function works as follows:

public String GetMembersList()
{
// We need to lock the app to enable syncronization

// The variable for the return message
String UserList = "";

// Every web application has an Application property
// which yields a handle to the ApplicationState object.
// ApplicationState object stores the collection of
// Member Objects (we will see latter how we do it).
// We obtain an array of the Keys to the collection
// and store the array in a variable 'Members'
String[] Members = Application.AllKeys;

// We can now unlock the application

Application.UnLock();

// Now we read the UserName variable in each Member
// object found in the HttpApplicationState State Collection
// and store these values in a string separated by
// NewLine Characters

for (int x=0;x

As the application involves multiple users - all accessing the same set of variables stored by us in the application object - we need to use Code Synchronization by invoking theLock andUnLock methods of theSystem.Web.HttpApplicationState State object whenever a write operation is performed by us.

In theRegisterMember method, we first check if the username supplied by the client is unique - if not, reject the name. Then, we instantiate a newMember object for the new participant and add the object to theApplicationState objects collection. We do these with the following code:


public string RegisterMember(String NickName)
{
CheckMembersList();
String[] Members = Application.AllKeys;
If ((Members.Length>0)&&(Array.IndexOf(Members,NickName)>-1))
{
throw new Exception("UserName Already Exists.
Please Select another name");
}
Member NewMember = new Member(NickName);
Application.Lock();
Application.Add(NickName, NewMember);
Application.UnLock();
return GetMembersList();
}


Again, all these are done in alocked state.

Whenever a client sends a message through theXchangeMsgs method, we first call theCheckMembers private method to update the list of chat participants in our collection. Then we check if the just received message carries a familiar Nick Name that is already registered with us. Then we loop through all theMember objects in our collection, open each of them and insert the just received message into theMessages variable of each of theseMember objects - after due HTML Formatting. Finally, we retrieve theMessages string stored in theMember object corresponding to the current client caller as the return value and empty theMessages variable of that object.

TheGetMsgs web method is similar to the above except that this method does not being us any new messages from the client and it is merely called to collect all the pending messages and the current list of chat participants.

Creating the Chat Client:
Our Chat Client is an HTML Web Page, which contains a table with 7 rows and one column. The first row contains the name of the Chat Application. The even numbered rows bear the captions and row number three contains the Chat Participants List whilst row five is for chat messages. The last row has a Text Box and a Submit button. Rows three and five house aelement within them, whosescroll property has been set toauto.

Attaching the WebService Behavior:
The table webservice behavior defined in the webservice_ver1.htc file, as follows:


id="service"
onresult="service_onmyresult();"
onready="this.style.visibility = 'visible';loading.style.display='none';"
border="0"
style=
"Background-Color:
White;Height:60%;
Border-Bottom:#A03399 solid 2px;
ForeColor:Black;
width:45%;
Behavior:url('http://localhost/dotnet/chatroom/webservice_ver1.htc');
Border-Left:#99ccff solid 2px;
Border-Right:#A03399 solid 2px;
Position:Relative;
Visibility:hidden;
Width:30%;
Border-Top:#99ccff solid 2px;
Table-Layout:Fixed;
Border-Style:#008080 solid 2px;">



The page has two script blocks of which one is invoked on theonLoad event of the window. This script block calls the use method of the webservice behavior by passing the URI of the webservice as a parameter as follows:





The other parameter supplied to the method is the name of the service ChatServe. The second code block initializes three variables called iCallID1,iCallID2 and iCallID3, to store the ID of the three web method calls. It also initializes anXMLDom ActiveX Object called Msg_XML, to enable us to store the SOAP messages returned by the web service.

When the user types his nick name in the Text Box and presses the submit button, an asynchronous call is made to the Web Service'sRegisterMember method, by invoking thecall method found in the webservice.htc. The method formats the SOAP request for theWeb Method, sends it to the web service host server using theXMLHttp object of theMSXML ActiveX object and returns the initializer for theiCallID1 variable. The DHTML Behavior ensures that when the webservice returns a SOAP Message from the server, anonResult event is fired upon the Table. The event handler for this event first checks up if the return value is an error message and if not, whether the return message is for the iCallID1. On passing these tests, the XML value of the result is stored in theXMLDom object called Msg_XML.

At this stage the XML returned by the server will resemble the following:




Prasad
Uriah
Charlotte



The Chat List in the return message, which isPrasad Uriah Charlotte is parsed out by applying the XPath pattern//UserList on the XML String and written into the table as the inner HTML of the Chat List panel as follows:


service_ChatList.innerText = service_MsgXML.selectSingleNode("//UserList").text;


The method then goes on to set a timer to invoke theGetMsgs method of the web service after 3 seconds. The return value of this method is parsed and placed as the inner HTML of the Chat List panel and the Chat Messages panel of the Table. This method sets up a timer to call itself once every 3 seconds.

Whenever the client types a message in the text box and presses the submit button, theXchangeMsgs method of the web service is invoked by the DHTML Behavior component. The return value of this method being similar to the one described above, is dealt with in the same manner.

This, in brief, is the designing of the client object. You will need to take a deeper look into theClientSide.html file given in the code download for this article to read the intricate details of the client side coding involved.

Making a control for the client side:
All that was described in the preceding section was the HTML code required to be supplied to the client browser. However, since ASP.NET is based on components, we need to make it easy for the web developer by encapsulating all these HTML code into a Control. Therefore, let us go on to create the ASP.NET custom control called TestWebControl. (See the code listing in the file TestWebControl.cs).

This control is derived from theSystem.Web.UI.WebControls.table object of the Framework. In it we override the protected method ofInit() and define various style elements for our component with the objective that the web developer using this control will have total say on how the control looks.

The properties we add to the control include oneBehaviorURI and one ServiceURI, which enable the control user to specify the URL of thewebservice.htc file on the server and the URI of the webservice. We, then, go on to instantiate new TableCell elements from the Framework, setting them with all the variables containing the css properties and finally adding them to our control - which is a sub class of the Table class. For this, we must first add the Table Cell into a newly instantiated TableRow element through its Cells Collection and the table row should be added to the Rows Collection of our control. Then, the client side scripts are all written into a string variable called Doc. An easy way of adding any script to the output document is to use theWrite Method of theHtmlTextWriter Object given to us when we override theRender Method. Therefore, to do the writing, we store the entire script block in thisDoc variable.

Finally we override the Render method of the Table class and write the scripts on to the client browser using theHtmlTextWriter object handed over to us by this method. We should not forget to call the base class'sRender Method, lest all our initialization code is left out of the page.

The Control thus created is used in any ASP.NET web form by inserting the following code: (You may change the URIs according to your server settings)













When running this application you will see a screen such as below that you can log on to and interact on.If you get someone else to log on to the page on to their computer you can have a conversation:



Summary
In this article we saw how to create a chat application using ASP.NET.Hopefully through this you will see the benefits of using ASP.NET for this sort of application and how by doing this you can avoid issues such as creating a server side listener.In this application you cannot log off yourself, but you can change the timing that people are logged on and inactive before being disconnected for longer than two minutes in the C sharp code.This article should help you develop your own ASP.NET chat applications.



[download relative material]

2LiHTML5中文学习网 - HTML5先行者学习网
2LiHTML5中文学习网 - HTML5先行者学习网