The requirements of the client have been analyzed before. Here is the client's business logic:
1. initialization: Initialize the user interface (mainly the list control) to create and enable the listener socket 2. user Logon: the pop-up logon dialog box allows the user to enter the user name, password, and server information to create a new socket connection Server Based on the server information entered by the user and request the user linked list to wait for the socket to read data. If it is an error message sent by the server the message box is displayed and logon fails. If the linked list is sent by the server, the logon is successfully refreshed. 3. offline message received: After the logon succeeds, the server checks whether there is any offline message for the user. After receiving the offline message, the client displays the message. If you click "reply, A new chat dialog box is created. 4. User chat: User chat is mainly completed in the chat dialog box, because it is not forwarded through the server, so each chat dialog box needs to maintain the necessary data for user chat. It mainly includes the user information and communication sockets of the communication parties and the active chat of some column objects (csocketfile carchive) that the user supports serialization: double-click a user in the list to start chatting. If the target user creates a chat dialog box online and connects to the target user (the connected socket is maintained by the chat dialog box), the chat dialog box is displayed. In this dialog box, complete the chat with the recipient. If the target user is created offline and the chat dialog box is displayed, after the dialog box is closed, the user input in the chat dialog box is obtained in the main window of the client, and send offline messages to the server (to avoid connecting to the server by sending only one offline message) passive chat: when the user's listening socket receives a new connection request, in this case, the user information requested for chatting (based on the IP Address requested by the user) is found in the user list for another user request chatting, and then the chat dialog box is created based on the information. Note: When a client logs on to the server, the IP address of its own information is obtained through the chat socket, while the port obtains the port of the listening socket (so that other users can send chat requests to you through the port in the user information ). Because the chat socket is managed by the chat dialog box, when the chat dialog box is closed by user A, the chat socket will also be destroyed. In this case, if user B of the chat continues to send messages, an error will occur. Therefore, after one party closes the dialog box, the other party closes the dialog box. For the communication mechanism with this program, there are probably the following ideas to solve this problem: If you want to destroy the socket after a user a closes the dialog box, when user B needs to send data again, reconnect to. This requires B to set up a variable bpeerwindowclose to identify whether a has closed the connection (the variable is set to true at onclose of the Communication socket and false after accept or connect is successful ), B checks the variable every time the data is sent to determine whether the connection needs to be re-requested (the connection socket needs to be updated after the connection ). Another solution is that a closes the dialog box and does not destroy the socket. In this way, the management right of the chat socket is handed over to the main window. When the socket itself has readable data, the main window is used to determine whether the corresponding window is opened, if the message is not displayed, open the window to display the message. Otherwise, the displayed message is passed in to the chat dialog box. When
B. When the dialog box is closed, the main window releases the chat socket. Complete source code click here: http://download.csdn.net/detail/wudaijun/4911762
