.NET开发：ASP.NET 开发聊天室程序(英文)

热点排行

ASP.NET 开发聊天室程序(英文)

类别：.NET开发点击：0 评论：0 推荐：

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.)
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.Services　and is contained in the source code file　ChatWebService.cs in the namespace PrasadWeb. The namespace also defines two other classes called　Member and ChatMessage. The class　Message has a string variable called UserName, a DateTime variable called　LastAccessTime and a public property NickName, which gets and sets the variable　UserName together with the time of his registration. The Class　ChatMessage has merely two string variables called　UserList and Messages. These two variables hold formatted lists of Chat Participants and the undelivered chat messages at any given time.

The main class　ChatWebService has two private methods　String 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. The　GetMemberList 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 the　Lock and　UnLock methods of the　System.Web.HttpApplicationState State object whenever a write operation is performed by us.

In the　RegisterMember method, we first check if the username supplied by the client is unique - if not, reject the name. Then, we instantiate a new　Member object for the new participant and add the object to the　ApplicationState 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 a　locked state.

Whenever a client sends a message through the　XchangeMsgs method, we first call the　CheckMembers 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 the　Member objects in our collection, open each of them and insert the just received message into the　Messages variable of each of these　Member objects - after due HTML Formatting. Finally, we retrieve the　Messages string stored in the　Member object corresponding to the current client caller as the return value and empty the　Messages variable of that object.

The　GetMsgs 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 a　
　element within them, whose　scroll property has been set to　auto. 

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 the　onLoad  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 an　XMLDom 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's　RegisterMember method, by invoking the　call method found in the webservice.htc. The method formats the SOAP request for the　Web Method, sends it to the web service host server using the　XMLHttp object of the　MSXML ActiveX object and returns the initializer for the　iCallID1 variable. The DHTML Behavior ensures that when the webservice returns a SOAP Message from the server, an　onResult 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 the　XMLDom 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 is　Prasad 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 the　GetMsgs 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, the　XchangeMsgs 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 the　ClientSide.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 the　System.Web.UI.WebControls.table object of the Framework. In it we override the protected method of　Init() 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 one　BehaviorURI and one ServiceURI, which enable the control user to specify the URL of the　webservice.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 the　Write Method of the　HtmlTextWriter Object given to us when we override the　Render Method. Therefore, to do the writing, we store the entire script block in this　Doc variable.
Finally we override the Render method of the Table class and write the scripts on to the client browser using the　HtmlTextWriter object handed over to us by this method. We should not forget to call the base class's　Render 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)
<%@ Register TagPrefix="Prasad" Namespace="PrasadWeb" %>








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]
本文地址：http://com.8s8s.com/it/it46365.htm

			
		

		
	

		Copyright © 2004-2013 信息技术中文网 All rights reserved 版权所有
		Powered by 信息技术中文网 Ver2.0