Introduction

In this chapter, we'll outline(提纲) the development of the Internet and the transport protocols that underpin(支撑) it. We'll review the evolution(演变) of the Winsock Application Programming Interface (API) from its origins. We will also examine the Winsock 1.1 and 2 architectures(架构), with particular emphasis(重点) on Winsock 2.

In the world of Windows, Winsock provides the crucial(决定性的,重要的) foundation upon which all Internet application run. Without Winsock, there would be no web browsers, no file transfer, and none of the e-mail applications that we take so much for granted(授予) in today's Windows environment. Technologies like DCOM and n-tier database systems would be difficult to implement.

Winsock is an API that is an integral part of Microsoft's Windows Open Systems Architecture (WOSA), which we'll discuss later in this chapter, as well as in the second half of the book dealing with TAPI. Let's start with the history of the genesis(成因) of the Internet to the present(礼物).

In the Beginning

Nowadays, it's easy to forget that the genesis of the Internet arose(产生) as a need for dependable(可靠) and robust(健全) communication network for military(军事) and government computers in the United States of America. In response(反应) to this need, in 1969 the Defense Advanced Research Project Agency (DARPA) sponsored an experimental(实验) network called Advanced Research Projects Agency Network (ARPANET).

Before the birth of ARPANET, for one computer to communicate with another on a network, both machines had to come from the same vendor. We call this arrangement(arrangement) a homogeneous(同质) network. In contrast, ARPANET, a collection of different computers linked together, was a heterogeneous network.

as ARPANET developed, it became popular for connected institutions(机构) to accomplish(完成) daily tasks such as e-mail and file transfer. In 1975, ARPANET became operational. However, as you might have already guessed, research into network protocols continued. Network protocols that developed early in the life of ARPANET evolved into a set of network protocols called the Transmission Control Protocol/Internet Protocol (TCP/IP) suite. The TCP/IP protocol suite became a Military Standard in 1983, which made it mandatory for all computers on ARPANET to use TCP/IP.

Note: For brevity, we use TCP/IP as a shorthand for TCP/IP suite.

In 1983, ARPANET split into two networks: MILNET for unclassified(机密) military use and ARPANET, which was the smaller of the two, for experimental (实验) research. These networks became known as Internet.

NOTE: The meaning of the Internet is just a collection of smaller networks to form a large network. Therefore, we can use the generic (通用) term internet to refer to a network of smaller network that is not the Internet.

The Internet expanded(扩大) futher when DARPA invited more universities to use the Internet for research and communications. In the early 1980s, however, university computer sites were using the Berkeley Software Distribution (BSD) UNIX, a variant of UNIX that did not have TCP/IP. DARPA funded Bolt Beranek and Newman, Inc. to implement TCP/IP in BSD UNIX. Thus TCP/IP became an intimate part of UNIX.

Although TCP/IP became an important communications provider in BSD UNIX, it was still difficult to develop network applications. Programmers at the University of Berkeley created an abstract layer to sit on top of TCP/IP, which became known as the Sockets layer. The version of BSD UNIX that incorporated the Socket layer for the first time is 4.2BSD, which was released in August 1983.

The Sockets layer made it easier and quicker to develop and maintain network applications. The Sokets layer became a catalyst (催化剂) for the creation of network applications, which further fueled (燃料) the expansion of the Internet. With the expansion of the Internet, TCP/IP became the network protocol of choice.

The following properties of TCP/IP explain the rapid acceptance of TCP/IP:
■ It is vendor independent, meaning an open standard.
■ It is a standard implementation on every computer form PCs to supercomputers.
■ It is used in local area networks (LANs) and wide area networks (WANs).
■ It is used by commercial (商业) entities实体(), government agencies(机构), and universites.

The Internet's rapid growth (and its continued growth) owes much to the development of the Hypertext Transfer Protocol (HTTP) that has provided the underpinnings for the World Wide Web. Rightly or wrongly, the ordinary man and woman on the street now sees the World Wide Web at the Internet. Internet protocols like HTTP, FTP, SMTP, and POP3 are high-level protocols that operate seamlessly on top of the network protocols collectively known as the TCP/IP protocol suite, or just TCP/IP. We'll describe briefly the network protocols that constitute the TCP/IP protocol suite in the netxt section.

Network Protocols

TCP/IP is a suite of network protocols upon which higher-level protocols, such as FTP, HPPT, SMTP, and POP3, operate. This suite comprises the two major protocols (TCP and IP) and a family of other protocols. We enumerate these as follows:
■ Transmission Control Protocol (TCP) is a connection-based protocol that provides a stable, full duplex (全双工) byte stream for an application. Application like FTP and HTTP use this protocol.
■ User Datagram Protocol (UDP) is a connectionless protocol that provides unreliable delivery of datagrams. (Note: Do not confuse "unreliable" with quality in this context. Unreliable refers to the possibility that some datagrams may not arrive at their destination, become duplicated (重复) or arrive out of sequence.) IP Multicast application use this protocol.
■ Internet Control Message Portocol (ICMP) is a protocol that handles error and control information between hosts. Application like ping and traceroute use this protocol.
■ Internet Portocol is a protocol that provides packet delivery for TCP, UDP, and ICMP.
■ Address Resolution Protocol (ARP) is a protocol that maps an Internet address into a hardware address.
■ Reverse Address Resolution Protocol (RARP) is a protocol that maps a hardware address into an Internet address.

Fortunately(幸运的), the BSD Sokets layer insulated (绝缘) the programmer from these protocols and, with some exceptions (例外), most network applications did not need to know the intimate (亲密) details of TCP/IP.

The OSI Network Model I

In 1977, the International Organization for Standardization (ISO) created a reference schema for networking computers together. This networking model is a guid, not a specification, for the construction of any network. This guide, Open System Interconnection (OSI), states that a network should provide seven layers as explained in Figure 1-1.

OSI Layer Numbers

1 Application <----- FTP, SMTP, POP3, HTTP
2 Presentation <----- Formats (e.g. encrypts or decrypts, compresses or decompress)
3 Session         <----- "Virtual" connection between computers
4 Transport <----- TCP/IP Protocol Suite (TCP/UDP)
5 Network         <----- IP Datagrams for routing - routes address packets for end to end communication.
6 Data Link <----- Satellite, Radio, LAN/WAN, Telephone
7 Physical <----- Ethernet Cards, Routers, etc.

If we map TCP/IP using the OSI network model, we get the following simplified diagram in Figure 1-2.

When a network application sends data to its peer across the network, the data is sent down throuth the layers to the data link and back up again throuth the layers on the peer's side. The following diagram makes this clear.

Before Winsock

In the early years of the Internet, computers that used the Internet were of the mainframe (大型机) and minicomputer (小型机) pedigree (系谱). Attached (附加的) to these computers were dumb (哑) terminals that were used for e-mail, file transfer, and network news. It was natural, therefore, that when PCs appeared on the scene, there was some demand for PCs to connect as "superior dumb terminals" to the Internet. In response to this demand, developers proted BSD Sockets to the various DOS platforms, such as MS-DOS and DR-DOS. Unfortunately, vendors developed their own brand of TCP/IP stacks that were not completely compatible with each other. This meant, of course, that network application developers had to develop different versions of their application to run on different stacks. This proliferation (扩散) of applications to run on difference stacks quickly became a maintenance (维修) nightmare (恶梦). This problem continued in the Windows environment when Windows 3.0 and 3.1 appeared in the early 1990s.

Evolution (进化) of Winsock

Winsock to the rescue (救援)! Development of network-aware applications became so problematic  (问题) that those leaders in the Windows communications industry organized a "Birds of a Feather" (BOF--狐朋狗友) conference (会议) at a prestigious (威望) trade (贸易) show in 1991.
At the end of the conference, delegates (代表) set up a committee (委员会) to investigate (调查) the creation of a standard API for TCP/IP for Widnows. This led to a specification that became Windows Sockets. The specification used much of BSD Sockets as its foundation. Windows 3.1 a "cooperative (合作)" multitasking operating system, which relied (依靠) on applications to yield (生产) quickly to avoid tying up resources such as the screen and mouse. Therefore, any Winsock application that blocked (for example, when waiting for data to arrive on a recv() function) would freeze the operatiing system, thus preventing (预防) any other application from running. To get around this major difficulty, the specification included modifications (修改) and enhancements (增强) that would permit (许可) a Winsock application to run asynchronously (异步) avoiding a total freeze.

For example, the specification included functions such as WSAAsyncGetHostByAddr() and WSAAsyncGetHostByName(), which are asynchronous versions of the gethostbyaddr() and gethostbyname() functions, respectively (分别). (We will examine the concept (概念) of blocking, non-blocking, and asynchronous operations later in the book.)

The first version of Wisnock (1.0) appeared in June 1992. After some revision, another version (Winsock 1.1) appeared in January 1993. With the introduction of Winsock, network applications proliferated (激增), making interfacing with the Internet easier than before.

One implementation of Winsock that soon became very common was Trumpet. Its developers took advantage of the Windows Dynamic Link Library (DLL) technology to house the Winsock API.

Some of the benefits of using Winsock include the following:
■ Provides an open standard
■ Provides application source code portability
■ Supports dynamic linking

Since its inception (成立), Winsock 1.1 has exceeded (超过) all expectations (期望). However, the API focuses on TCP/IP to the exclusion (排斥) of other protocol suites. This was a deliberate (蓄意) and strategic decision (战略决策) to encourage (鼓励) vendors of TCP/IP stacks to use the Windows Sockets specification in the early years. It worked!

Winsock is now the networking API of choice for all Windows platforms. Windows Sockets Version 2 addresses the need to use protocol suites other than TCP/IP. The Winsock 2 API can handle disparate (不同的) protocol suites like DecNet, IPX/SPX, ATM, and many more. We call this capaility multiple protocol support, or simply protocol independence (独立). This degree of flexibility permits (允许) the development of generic network services. For example, an application could use a different protocol to perform one task and another for a different task. Although Winsock 2 adds new, flexible, and powerful features to the original API, the API is backward compatible with Version 1.1. This means that existing network applications developed for Winsock 1.1 can run with out change under Winsock 2.

The Winsock Architecture
Winsock 1.1

As you have no doubt (怀疑) already deduced (推导), the main difference between the two Winsock versions we're disscussing is that Winsock 1.1 uses the TCP/IP portocols suite exclusively (仅仅), whereas Winsock 2 supports other protocols, such as AppleTalk, IPX/SPX, and many others, as well as TCP/IP. Figure 1-4 shows the simple interaction (互动) between a Winsock 1.1 application with the WINSOCK.DLL or WSOCK.DLL. Because of its support for multiple protocols, the architecture of Winsock 2 is necessarily more complex.

Winsock 2

Winsock 2 follows the Windows Open Systems Architecture (WOSA) model. In the WOSA model, the structure has two distinct parts; one is the API for application developers, and the other is the Service Povider Interface (SPI) for protocol stack and name space service providers. This two-tier arrangement allows Winsock to provide multiple protocol support, while using the same API. For example, an application that uses the ATM protocol will use the same API as the application that uses TCP/IP.

To make this clearer, take the scenario (情景) of a Winsock 2 server application that has several installed protocols (for example, ATM, TCP/IP, IPX/SPX, and AppleTalk). Because the server has access to each of these protocols, it can transparently service requests from different client that are using any of the supported protocols.

The concept (概念) of the Service Provider Interface allows different vendors to install their own brand (烙印) of transport protocol, such as NetWare's IPX/SPX. In addition to providing (transport) protocol independence, the Winsock 2 architecture also provides name space independence. Like the transport protocols, the SPI allows vendors to install their name space providers, which provides resolution of hosts, services, and protocols. The Domain Name System (DNS) that we use for resolving hosts on TCP/IP is an example of a name space provider. NetWare's Service Advertisement Portocol (SAP) is another. This capability enables any application to select the name space provider most suited to its needs. Figure 1-5 displays the Winsock 2 architecture. We'll discuss more details on protocol and name space independence (独立) in the next section.

New Features of Winsock

Although we'll examine most of these new functions in detail in the chapters to come, we'll complete our overview of Winsock by enumerating these new features briefly.

Multiple Protocol Support
Like BSD Sockets before it, Winsock 2 provides simultaneous (兼) multiple protocol support. Winsock 2 has functions to allow an application to be protocol independent.

Name Space Independence
Name registration is a process that associates a protocol-specific address with a user-friendly name. For example, users find it easier to remember the address of Wordware Publishing, which is wordware.com, than a numeric address like 150.09.23.78. To make this possible, we use the Domain name System (DNS) on TCP/IP to resolve host names to their IP addresses and vice versa (反之亦然).

There are three different types of name spaces: static, persistent (持久性), and dynamic. DNS is a static service, which is the least flexible. It is not possible to register a new name from Winsock using DNS. Dynamic name space, on the other hand, allows registration on the fly. An example of a persistent name space is Netware Directory Service (NDS).

Service Advertising Protocol (SAP) is a protocol for announcing dynamic name space changes on NDS.

Unlike Winsock 1.1, Winsock 2 can support multiple independent name space services in addition to the familiar DNS for TCP/IP.

Scatter (发散) and Gather (聚合)
The support for "scatter and gather" is similar to the vectored I/O as supported by BSD Sockets.

Overlapped I/O
Winsock2 uses the overlapped I/O model from the Win32 API. We will explain these functions in Chapter 5, "Communications."

Quality of Service
With the increasing use of multimedia applications that require a varying and often large bandwidth along with demanding timing requirements, the use of Quality of Service has become an important tool to manage network traffic (交通). We will not discuss this tool, as it is beyond the scope of this book.

Multipoint and Multicast
Although Winsock 1.1 provides basic support for IP Multicast, Winsock 2 provides additional APIs that extend support for protocol-independent multipoint and multicast datagram trasmission.

Conditional Acceptance
Winsock 2 provides the capability to examine the attributes of a connection request before accepting or rejecting the request. Using a call back function, WSAAccept() captures the attributes, such as caller's address, QOS information, and any connect data. After processing the data gleaned from the connection request, the application calls WSAAccept() again to accept, defer, or reject the request.

Connect and Disconnect Data
The new functions that support this feature are WSAAccept(), WSARecv-Disconnect(), WSASendDisconnect(), and WSAConnect().

Socket Sharing
Winsock 2 provides a means of sharing sockets between processes (but not between threads). The new function that provides this feature is WSADuplicateSocket(). A process that requires sharing an existing socket does so through existing interprocess (进程间) mechanisms like DDE, OLE, an others. However, the data itself is not shared, and each process needs to create its own event objects via calls to WSACreateEvent().

Protocol-specific Addition
Although Winsock 2 provides a consistent (一致) API, some protocols require additional data structures that are specific to a particular protocol. For example, ATM has extra data structures and special constants for its protocol. Although our focus is on the TCP/IP protocols, we have provided Delphi Interface units that translate the C headers containing the data structures for some of these protocols, such as AppleTalk, ATM, NETBIOS, ISO TP4, IPX/SPX, and BANYAN VINES.

Socket Groups
Winsock 2 introduces the concept of socket groups. An application can create a set of sockets with each socket dedicated to a specific task. However, in the current version (2.2), this feature is not yet supported, so we will not discuss it.

Summary
In this chapter, we covered the origins of the Internet, which led to the establishment (建立) of TCP/IP as the protocol suite of choice. We reviewed the evolution of Winsock from BSD Sockets and briefly covered the Winsock2 architecture and its new features. To simplify coverage of the Winsock 2 API in the following chapters, the functions are groupd by the following topics:

Table 1-1: Function groups

         Topic      Chapter
Starting and closing Winsock   Chapter 2
Winsock error handling    Chapter 2
Winsock 1.1 resolution    Chapter 3
Winsock 2 resolution    Chapter 4
Communications     Chapter 5
Network events     Chapter 5
Socket options     Chapter 6

For the majority of these functions, we'll demonstrate their usage with example code.

NOTE: These APIs are in the Winsock2.pas file on the companion CD that comes with this book. This file should be on a path visible to Delphi. By convention, you should put the Winsock2.pas file in the directory \Delphi7\Lib.