1. Introduction Internet internet access, browsing, FTP, Gopher, in WWW, and in terms of network phones, multimedia conferences, etc., have become hot spots in strict applications of real-time requirements, and it is already necessary. The most basic method for communicating programming in the Windows environment is to apply communication between the WindowsSockets implementation process. For this Microsoft, Microsoft provides a large number of WindowsSockets-based communication APIs, such as WinsockApi, WinineTAPI, and ISAPI, and has been committed to developing faster, easier Communication API, integrate it with MFC to make communication programming more and more easily. The MFC is the most important component of the VC programming environment, which provides users with a large number of pre-defined classes and member functions, encapsulated a lot of WindowsAPI. At the same time, VC environments provide special tools that work with MFC objects and code: AppStudio Source Editor, AppWizard, and ClassWizard. To apply MFC, you can develop complex communication applications with less time and effort.
This article describes some of the experience in developing real-time network audio tools Freetalk, introduces the common API and encapsulates their MFC classes in the Windows environment. It is important to introduce the method of writing network communication programs using MFC's CasyncSocket and CSocket classes. The class encapsulates WinsockApi and makes them easier to use and more adapt to the MFC programming environment.
Second, the communication API and the corresponding MFC class 1.Windowssockets (Winsock) API WindowsSockets define the Windows network programming interface, which is based on Berkeley UnixSockets, Berkeley, California. WindowsSockets include both BSD-style routines, also adds to the Windows extension, such as the extended function for message-driven. Windowssockets can run on many network protocols, including TCP / IP, XNS, DECNET, IPX / SPX, etc. In Win32 Environment, WindowsSockets offers thread security. Through Microsoft and Standards Treatments, Winsock defines the application design interface (WinsockApi), which can easily use the next network protocol (such as TCP / IP) to communicate.
By providing two class CasyncSocket and CSocket, MFC supports the use of WinsockAPI communication programming. MFC encapsulates complex WinsockApi into classes, which makes it easier to write applications. The CasyncSocket class packages WinsockApi one by one, providing a more powerful and flexible way for advanced network programmers. This class is based on programmers to understand network communication, and the purpose is to use Winsock in MFC, programmers have responsibility to handle tasks such as blocking, byte order, and convert characters between Unicode and MBCs. In order to provide a more convenient interface to automatically handle these tasks, the MFC gives the CSocket class, which is inherited by the CasyncSocket class, which provides a WinsockAPI interface than the CasyncSocket higher. The CSocket class and the CSocketFile class work together with the CARCHIVE class to manage the sending and receiving data, which makes management data more convenient. The CSocket object provides blocking mode, which is critical to the synchronization operation of CARCHIVE. Blocking functions [such as Receive (), send (), received (), returned to control after the operation is completed, so use the CasyncSock class if low-level control and high efficiency are required; if you need to be convenient You can use the CSocket class. 2.WIN32Internet (Wininet) API Microsoft announced some of the design of the Internet application than before, easier API: WinineTAPI, which provides a medium-high-level communication function, which makes access to the main Internet protocols are quite easy. These functions provide an isolation layer between programmers and Winsock drivers. There are 4 types of WinineTAPI functions: General Wininet Functions, Wininet File Transfer Protocol (FTP) Functions, WinineTgopher functions, Wininet Hypertext Transfer Protocol (HTTP) functions.
In fact, the MFC and the ActiveX technology WinInetAPI encapsulated classes that allow Internet programming easier, these classes include CInternetSession, CInternetConnection, CInternetFile, CHttpConnection, CHttpFile, CGopherFile, CFtpConnection, CGopherConnection, CFileFind, CFtpFileFind, CGopherFileFind, CGopherLocator and CInternetException.
3. Internet Server API (ISAPI)
Microsoft's IIS is the only WWW server that is closely integrated with the WindowsNTServer operating system, which is wide as the Internet / Intranet server application. IIS allows the extension function, which is implemented by ISAPI, and ISAPI describes an interface between the Internet server. Tools with ISAPI can establish high performance, high efficiency, business safety and Internet server that meets new IIS standards. Similarly, ISAPI is encapsulated by typical classes in MFC, including Chttpfilter, ChttpFilterContext, Chttpserver, ChttpserverContext, RelatedClasses, and ChtmlStream.
Third, WinsockAPI's MFC package class Some web applications (such as VoIP, Multimedia Conference Tools) Real-time requirements are very strong, requiring Data to send and receive data directly. At this time, the designer should choose to directly apply WinsockAPI or WinsockApi encapsulated by the MFC. In the newly developed application, in order to take advantage of the MFC, the preferred program should be the CasyncSocket class and CSocket class in the MFC, which fully encapsulates WinsockApi and provides more convenience. This article introduces the application model of the application of these two classes, and leads out the relevant member functions and some interpretation of the concept. The inheritance of the CasyncSocket class and the CSocket class and the CasyncSocket class and the CSocket class are given by the drawings. The CSocket class is inherited by CasyncSocket. In fact, CasyncSocket encapsulates WinsockApi one by one in the MFC. Each CasyncSocket object represents a WindowsSocket, which is familiar with the programmer using the CasyncSocket class. Compared to the CSocket class is the derived class of CasyncSocket, inheriting the WinsockApi it encapsulated. A CSocket object represents a higher level of WindowsSocket abstraction than CasyncSocket objects, and the CSocket class works with the CSocketFile class and the Carchive class to send and receive data, so it is easier to use. The CSocket object provides blocking mode because the blocking function is critical to the synchronization operation of CARCHIVE. It is necessary to explain the concept of blocking here: A socket can be in "blocked mode" or "non-blocking mode", when a socket is in blocking mode (ie synchronous operation), its blocking function is not completed Will return control, the reason why the blocking is because the blocking function of this socket cannot be done before the operation is completed. If a socket is in a non-blocking mode (ie, an asynchronous operation), the call function will be returned immediately. In the CasyncSocket class, you can query the last error with the getLastError member function. If the error is WSAEWOULDBLOCK, it will explain to block, and CSocket will never return WSAEWOULDBLOCK because it manages it yourself. Microsoft recommends trying to use a non-blocking mode to notify the application to perform the appropriate processing through the occurrence of network events. However, in the CSocket class, some member functions always have blocking properties in order to make many of the problems and simplified programming in the CARCHIVE handling communication, because the CARCHIVE class needs to be synchronized. In the Win32 environment, if you want to use a socket with blocking properties, you should put it in a separate worker thread. Use multithreading methods to make the blocking unable to interfere with other threads, and do not waste the CPU time in blocking. Multi-threaded methods can make the programmer to enjoy the simplified programming of CSocket, nor does it affect the user's response to the user. 2. CasyncSocket class programming model
In an MFC application, you can easily handle multiple network protocols, while you don't sacrifice flexibility, you can consider using the CasyncSocket class, which is higher than that of the CSocket class. The programming model for the CasyncSocket class is briefly described as follows:
(1) Construct a CasyncSocket object and generate a Socket handle with this object's CREATE member function. It can be constructed as follows:
CasyncSocketSock; Sock.create (); file: // Generate a word-of-band jacket or casyncSocket * psocket = newcasyncSocket; intnport = 27; psocket-> create (nport, sock-dgram); file: // The specified port number generates a data settlement of the first method to generate a CasyncSocket object on the stack, and the second method produces a CasyncSocket object on the heap. The first CREATE member function generates a word-of-line jacket with a default parameter, and the second CREATE member function generates a digital reported sheet with the specified port and address. The parameters of CREATE are: 1 port, uint type. Note: If it is a service party, use a well-known port for service party; if it is a client, typical approach is to accept the default parameters, so that the socket can choose an available port independently;
2Socket type. Sock-stream (default) or sock-dgram;
3Socket address. For example, "ftp.gliet.edu.cn" or "202.193.64.33".
(2) If the client program is connected to the service party with the CasyncSocket: If the server program is used, use the CasyncSocket: The CasyncSocket is starting to listen. Once the connection request is received, call the CasyncSocket: The CasyncSocket: The CasyncSocket is started to start receiving. Note: CASYNCSOCKET: The function is used as a new and empty CSocket object as its parameters, which "empty" refers to this new object has not called the Create member function.
(3) Call the other CasyncSocket class member functions for communication management.
(4) After the communication is over, destroy the CasyncSocket object. If the CasyncSocket object generated on the stack, the object is automatically destructed when the object is exceeded; if it is generated on the heap, it is used to use the NEW operator, you must use the DELETE operator destroy CasyncSocket object.
3.csocket class programming model
Use the CSocket object involved Carchive and CSocketFile class objects. In the following steps describing the steps of the byte stream socket, only the third step is different for the client and the server, and other steps are the same.
(1) Construct a CSocket object.
(2) Use the CREATE member function of this object to generate a Socket handle. In the client program, unless you need a data settlement, Create usually use the default parameters. For service program, you must specify a port when CREATE is called. Note: CARCHIVE cannot work with the datagram (UDP) socket, so the use of CasyncSocket and CSocket is the same for data setsters, CasyncSocket and CSocket.
(3) If it is a client plug-in, call CasyncSocket: If it is a service-socket, call CasyncSocket: If it is a service-socket, call CasyncSocket, start to listen to the connection request from the client, receive the connection request. After calling CasyncSocket: The request is accepted to establish a connection. Note: The Accept member function requires a new and empty CSocket object as its parameters, explains the same.
(4) Generate a CSocketFile object and associate it with the CSocket object.
(5) Generate a CARCHIVE object for receiving and transmitting data, associating them with the CSocketFile object. Remember that Carchive is not working with the data report set. (6) Use the CARCHIVE object to transfer data to the service party. (7) After the communication is completed, destroy Carchive, CSocketFile, and CSocket objects.
