Chapter 7: Winsock Basics
This chapter is dedicated to learning the basic techniques and API calls necessary for writing successful network applications. In the last chapter, you learned how each protocol accessible from Winsock addresses machines and services on those machines. In this chapter, we’ll look at establishing a connection from one machine on the network to another, along with how tosend and receive data. For simplicity’s sake, and to prevent repetition, the discussion in this chapter is limited to the TCP/IP protocol. However, this book’s companion CD contains client/server samples for each of the protocols covered in Chapter 6. The only protocol-dependent operation is socket creation. Most of the remaining Winsock calls that are required for establishing a connection andfor sending and receiving data are independent of the underlying protocol. The exceptions were noted in Chapter 6 along with each protocol discussion.
The examples presented in this chapter help to provide an understanding of the Winsock calls that are required for accepting connections, establishing connections, and sending and receiving data. Because the purpose of this chapter is to learn theseWinsock calls, the examples presented use straight blocking Winsock calls. Chapter 8 presents the different I/O models available in Winsock, including code examples.
Additionally, in this chapter we will present both the Winsock 1 and Winsock 2 versions of the various API functions. You can differentiate the two functions with the WSA prefix. If Winsock 2 updated or added a new API function in itsspecification, the function name is prefixed with WSA. For example, the Winsock 1 function to create a socket is simply socket. Winsock 2 introduces a newer version named WSASocket that is capable of using some of the new features made available in Winsock 2. There are a few exceptions to this naming rule. WSAStartup, WSACleanup, WSARecvEx, and WSAGetLastError are in the Winsock 1.1specification.
Every Winsock application must load the appropriate version of the Winsock DLL. If you fail to load the Winsock library before calling a Winsock function, the function will return a SOCKET_ERROR and the error will be WSANOTINITIALISED. Loading the Winsock library is accomplished by calling the WSAStartup function, which is defined as
The wVersionRequested parameter is used to specify the version of the Winsock library you want to load. The high-order byte specifies the minor version of the requested Winsock library, while the low-order byte is the major version. You can use the handy macro MAKEWORD(x, y), in which x is the high byte and y is the low byte, to obtain the correct value forwVersionRequested.
The lpWSAData parameter is a pointer to a LPWSADATA structure that WSAStartup fills with information related to the version of the library it loads:
typedef struct WSAData
char szDescription[WSADESCRIPTION_LEN + 1];
char szSystemStatus[WSASYS_STATUS_LEN + 1];
unsigned short iMaxSockets;unsigned short iMaxUdpDg;
char FAR * lpVendorInfo;
} WSADATA, FAR * LPWSADATA;
WSAStartup sets the first field, wVersion, to the Winsock version you will be using. The wHighVersion parameter holds the highest version of the Winsock library available. Remember that in both of these fields, the high-order byte represents the Winsock minor version, while the low-order byte is the majorversion. The szDescription and szSystemStatus fields are set by the particular implementation of Winsock and aren’t really useful. Do not use the next two fields, iMaxSockets and iMaxUdpDg. They are supposed to be the maximum number of concurrently open sockets and the maximum datagram size; however, to find the maximum datagram size you should query the protocol information through WSAEnumProtocols....
Ler documento completo
Por favor, assinar para o acesso.