WINSOCK There was some discussion about how best to

address the copyright, intellectual property, and

potential anti-trust issues, and consideration was
Origins of Windows Sockets given to working through the IETF or
Background establishing a non-profit foundation. In the end, it
Early Microsoft operating systems, both MS- was decided that the specification would simply
DOS and Windows, offered limited networking be copyrighted by the four authors as
capability, chiefly based on NetBIOS (a (unaffiliated) individuals.
technology that Microsoft adopted from IBM). In
particular, Microsoft completely ignored the The WinSock Specification
TCP/IP protocol stack. A number of university
groups and commercial vendors, including the The Windows Sockets specification defines a
PC/IP group at MIT, FTP Software, Sun network programming interface for Microsoft
Microsystems, Ungermann-Bass, and Excelan, Windows which is based on the "socket"
introduced TCP/IP products for MS-DOS, often paradigm popularized in the Berkeley Software
as part of a hardware/software bundle. When Distribution (BSD) from the University of
Microsoft Windows was released, these vendors California at Berkeley. It encompasses both
were joined by others such as Distinct and familiar Berkeley socket style routines and a set
NetManage in offering TCP/IP for Windows. of Windows-specific extensions designed to
Even Microsoft offered a limited-function allow the programmer to take advantage of the
product. message-driven nature of Windows.
The drawback faced by all of these vendors was The Windows Sockets Specification is intended
that each of them used their own API. Without a to provide a single API to which application
single standard programming model, it was developers can program and multiple network
difficult to persuade independent software software vendors can conform. Furthermore, in
developers to create networking applications, and the context of a particular version of Microsoft
end users were wary of getting locked in to a Windows, it defines a binary interface (ABI) such
single vendor. that an application written to the Windows
Sockets API can work with a conformant
Earlier Efforts
protocol implementation from any network
There had been a number of successful software vendor. This specification thus defines
standardization efforts in the PC networking area the library calls and associated semantics to
over the years. The first of these was a program which an application developer can program and
sponsored by the US Air Force to develop which a network software vendor can implement.
RFC1001/1002, a NetBIOS implementation
running over TCP/IP. A second was the Crynwr
packet driver effort initiated by FTP Software and ØThe Winsock specification defines two
led by Russ Nelson. interfaces:
à the API used by application developers,
Finally...
and
WinSock was proposed by Martin Hall of JSB à the SPI, which provides a means for
Software (later Stardust Technologies) at the network software developers to add new
Interop in October 1991, during a "Birds of a protocol modules to the system.
Feather" session. The first edition of the
specification was authored by Martin Hall, Mark ØEach interface represents a contract.
Towfiq of Microdyne (later Sun Microsystems), à The API guarantees that a conforming
Geoff Arnold of Sun Microsystems, and Henry application will function correctly with a
Sanders of Microsoft, with assistance from many conformant protocol implementation from
others. any network software vendor.
1
 à The SPI contract guarantees that a is expected that this will facilitate the creation of
conforming protocol module may be added to robust and high-performance applications, and
Windows and will thereby be usable by an will improve the cooperative multitasking of
API-conformant application. applications within non-preemptive versions of
ØAlthough these contracts were important when Windows. With the exception of WSAStartup()
Winsock was first released, they are now of and WSACleanup() their use is not mandatory.
only academic interest. Microsoft has shipped a
high-quality TCP/IP stack with all recent
versions of Windows, and there are no
Programming
significant independent alternatives. Nor has Windows Sockets Stack Installation
there been significant interest in implementing Checking
protocols other than TCP/IP. To detect the presence of one (or many)
Windows Sockets implementations on a system,
an application which has been linked with the
Winsock is based on BSD sockets, but provides Windows Sockets Import Library may simply
additional functionality to allow the API to call the WSAStartup() routine. If an application
comply with the standard Windows programming wishes to be a little more sophisticated it can
model. The Winsock API covered almost all the examine the $PATH environment variable and
features of the BSD sockets API, but there were search for instances of Windows Sockets
some unavoidable obstacles which mostly arose implementations (WINSOCK.DLL). For each
out of fundamental differences between Windows instance it can issue a LoadLibrary() call and
and Unix. use the WSAStartup() routine to discover
However it was a design goal of Winsock that it implementation specific data.
should be relatively easy for developers to port
socket-based applications from Unix to
Windows. It was not considered sufficient to Sockets - Basic Concepts
create an API which was only useful for newly- The basic building block for communication is
written Windows programs. For this reason, the socket. A socket is an endpoint of
Winsock included a number of elements which communication to which a name may be bound.
were designed to facilitate porting. For example, Each socket in use has a type and an associated
Unix applications were able to use the same process. Sockets exist within communication
errno variable to record both networking errors domains. A communication domain is an
and errors detected within standard C library abstraction introduced to bundle common
functions. Since this was not possible in properties of threads communicating through
Windows, Winsock introduced a dedicated sockets. Sockets normally exchange data only
function, WSAGetLastError(), to retrieve error with sockets in the same domain (it may be
information. Such mechanisms were helpful, but possible to cross domain boundaries, but only if
application porting remained extremely complex. some translation process is performed). The
Many "traditional" TCP/IP applications had been Windows Sockets facilities support a single
implemented by using system features specific to communication domain: the Internet domain,
Unix, such as pseudo terminals and the fork which is used by processes which communicate
system call, and reproducing such functionality in using the Internet Protocol Suite.
Windows was problematic. Within a relatively
short time, porting gave way to the development Sockets are typed according to the
of dedicated Windows applications. communication properties visible to a user.
The Microsoft Windows extensions included in Applications are presumed to communicate only
Windows Sockets are provided to allow between sockets of the same type, although there
application developers to create software which is nothing that prevents communication between
conforms to the Windows programming model. It sockets of different types should the underlying
2
communication protocols support this. which support only in-band signaling (i.e. the
Two types of sockets currently are available to a urgent data is delivered in sequence with the
user. normal data), the system normally extracts the
Ø A stream socket provides for the bi-directional, data from the normal data stream and stores it
reliable, sequenced, and unduplicated flow of separately. This allows users to choose between
data without record boundaries. receiving the urgent data in order and receiving it
ØA datagram socket supports bi-directional flow out of sequence without having to buffer all the
of data which is not promised to be sequenced, intervening data. It is possible to ``peek'' at out-
reliable, or unduplicated. That is, a process of-band data.
receiving messages on a datagram socket may An application may prefer to process out-of-band
find messages duplicated, and, possibly, in an data "in-line", as part of the normal data stream.
order different from the order in which it was This is achieved by setting the socket option
sent. An important characteristic of a datagram SO_OOBINLINE. In this case, the application may
socket is that record boundaries in data are wish to determine whether any of the unread data
preserved. Datagram sockets closely model the is "urgent" (the term usually applied to in-line
facilities found in many contemporary packet out-of-band data). To facilitate this, the Windows
switched networks such as Ethernet. Sockets implementation will maintain a logical
"mark" in the data stream to indicate the point at
Out-of-band data which the out-of-band data was sent. An
Note: The following discussion of out-of-band application can use the SIOCATMARK ioctlsocket()
data, also referred to as TCP Urgent data, follows command to determine whether there is any
the model used in the Berkeley software unread data preceding the mark. For example, it
distribution. Users and implementors should be might use this to resynchronize with its peer by
aware of the fact that there are at present two ensuring that all data up to the mark in the data
conflicting interpretations of RFC 793 (in which stream is discarded when appropriate.
the concept is introduced), and that the The WSAAsyncSelect() routine is particularly
implementation of out-of-band data in the well suited to handling notification of the
Berkeley Software Distribution does not conform presence of out-of-band-data.
to the Host Requirements laid down in RFC
1122. To minimize interoperability problems,
Broadcasting
applications writers are advised not to use out-of-
band data unless this is required in order to By using a datagram socket, it is possible to send
interoperate with an existing service. Windows broadcast packets on many networks supported
Sockets suppliers are urged to document the out- by the system. The network itself must support
of-band semantics (BSD or RFC 1122) which broadcast: the system provides no simulation of
their product implements. broadcast in software. Broadcast messages can
place a high load on a network, since they force
The stream socket abstraction includes the notion every host on the network to service them.
of ``out of band'' data. Out-of-band data is a Consequently, the ability to send broadcast
logically independent transmission channel packets has been limited to sockets which are
associated with each pair of connected stream explicitly marked as allowing broadcasting.
sockets. Out-of-band data is delivered to the user Broadcast is typically used for one of two
independently of normal data. The abstraction reasons: it is desired to find a resource on a local
defines that the out-of-band data facilities must network without prior knowledge of its address,
support the reliable delivery of at least one out- or important functions such as routing require
of-band message at a time. This message may that information be sent to all accessible
contain at least one byte of data, and at least one neighbours.
message may be pending delivery to the user at
any one time. For communications protocols The destination address of the message to be
3
broadcast depends on the network(s) on which different, the conversions described above are
the message is to be broadcast. The Internet unavoidable. Application writers are cautioned
domain supports a shorthand notation for that they should use the standard conversion
broadcast on the local network, the address functions provided as part of the Windows
INADDR_BROADCAST. Received broadcast Sockets API rather than writing their own
messages contain the senders address and port, as conversion code, since future implementations of
datagram sockets must be bound before use. Windows Sockets are likely to run on systems for
Some types of network support the notion of which the host order is identical to the network
different types of broadcast. For example, the byte order. Only applications which use the
IEEE 802.5 token ring architecture supports the standard conversion functions are likely to be
use of link-level broadcast indicators, which portable.
control whether broadcasts are forwarded by
bridges. The Windows Sockets specification does Blocking/Non blocking & Data Volatility
not provide any mechanism whereby an One major issue in porting applications from a
application can determine the type of underlying Berkeley sockets environment to a Windows
network, nor any way to control the semantics of environment involves "blocking"; that is,
broadcasting. invoking a function which does not return until
the associated operation is completed. The
Byte Ordering problem arises when the operation may take an
The Intel byte ordering is like that of the DEC arbitrarily long time to complete: an obvious
VAX, and therefore differs from the Internet and example is a recv() which may block until data
68000-type processor byte ordering. Thus care has been received from the peer system. The
must be taken to ensure correct orientation. default behavior within the Berkeley sockets
model is for a socket to operate in a blocking
Any reference to IP addresses or port numbers mode unless the programmer explicitly requests
passed to or from a Windows Sockets routine that operations be treated as non-blocking.
must be in network order. This includes the IP
address and port fields of a struct ØIt is strongly recommended that programmers
sockaddr_in (but not the sin_family field).
use the nonblocking (asynchronous) operations
if at all possible, as they work significantly
better within the nonpreemptive Windows
Consider an application which normally contacts environment. Use blocking operations only if
a server on the TCP port corresponding to the absolutely necessary, and carefully read and
"time" service, but which provides a mechanism understand this section if you must use
for the user to specify that an alternative port is to blocking operations.
be used. The port number returned by Even on a blocking socket, some operations (e.g.
getservbyname() is already in network order, bind(), getsockopt(), getpeername()) can be
which is the format required constructing an completed immediately. For such operations
address, so no translation is required. However if there is no difference between blocking and non-
the user elects to use a different port, entered as blocking operation. Other operations (e.g. recv())
an integer, the application must convert this from may be completed immediately or may take an
host to network order (using the htons() function) arbitrary time to complete, depending on various
before using it to construct an address. transport conditions. When applied to a blocking
Conversely, if the application wishes to display socket, these operations are referred to as
the number of the port within an address blocking operations. All routines which can block
(returned via, e.g., getpeername()), the port are listed with an asterisk in the tables above and
number must be converted from network to host below.
order (using ntohs()) before it can be displayed.
Within a Windows Sockets implementation, a
Since the Intel and Internet byte orders are
4
blocking operation which cannot be completed WSAAsyncSelect() both set a socket to
immediately is handled as follows. The DLL nonblocking mode.) If an application uses only
initiates the operation, and then enters a loop in non-blocking sockets and uses the
which it dispatches any Windows messages WSAAsyncSelect() and/or the
(yielding the processor to another thread if WSAAsyncGetXByY() routines instead of
necessary) and then checks for the completion of select() and the getXbyY() routines, then the
the Windows Sockets function. If the function blocking hook will never be called and the
has completed, or if WSACancelBlockingCall() application does not need to be concerned with
has been invoked, the blocking function the reentrancy issues the blocking hook can
completes with an appropriate result. Refer to introduce.
WSASetBlockingHook(), for a complete If an application invokes an asynchronous or non-
description of this mechanism, including blocking operation which takes a pointer to a
pseudocode for the various functions. memory object (e.g. a buffer, or a global variable)
If a Windows message is received for a process as an argument, it is the responsibility of the
for which a blocking operation is in progress, application to ensure that the object is available
there is a risk that the application will attempt to to the Windows Sockets implementation
issue another Windows Sockets call. Because of throughout the operation. The application must
the difficulty of managing this condition safely, not invoke any Windows function which might
the Windows Sockets specification does not affect the mapping or addressability of the
support such application behavior. Two functions memory involved. In a multithreaded system, the
are provided to assist the programmer in this application is also responsible for coordinating
situation. WSAIsBlocking() may be called to access to the object using appropriate
determine whether or not a blocking Windows synchronization mechanisms. A Windows
Sockets call is in progress. Sockets implementation cannot, and will not,
WSACancelBlockingCall() may be called to address these issues. The possible consequences
cancel an in-progress blocking call, if any. Any of failing to observe these rules are beyond the
other Windows Sockets function which is scope of this specification.
called in this situation will fail with the error
WSAEINPROGRESS. It should be emphasized Asynchronous select() Mechanism
that this restriction applies to both blocking and
non-blocking operations. The WSAAsyncSelect() API allows an
application to register an interest in one or many
Although this mechanism is sufficient for simple network events. This API is provided to
applications, it cannot support the complex supersede the need to do polled network I/O. Any
message-dispatching requirements of more situation in which select() or non-blocking I/O
advanced applications (for example, those using routines (such as send() and recv()) are either
the MDI model). For such applications, the already used or are being considered is usually a
Windows Sockets API includes the function candidate for the WSAAsyncSelect() API. When
WSASetBlockingHook(), which allows the declaring interest in such condition(s), you supply
programmer to define a special routine which will a window handle to be used for notification. The
be called instead of the default message dispatch corresponding window then receives message-
routine described above. based notification of the conditions in which you
The Windows Sockets DLL will call the blocking declared an interest.
hook function only if all of the following are true: WSAAsyncSelect() allows interest to be declared
the routine is one which is defined as being able in the following conditions for a particular
to block, the specified socket is a blocking socket:
socket, and the request cannot be completed
immediately. (A socket is set to blocking by à Socket readiness for reading
default, but the IOCTL FIONBIO and à Socket readiness for writing

5
 à Out-of-band data ready for reading WSAGetLastError() returns error codes which
à Socket readiness for accepting incoming avoid conflict with standard Microsoft C error
connection codes. Certain error codes returned by certain
à Completion of non-blocking connect() Windows Sockets routines fall into the standard
à Connection closure range of error codes as defined by Microsoft C. If
you are NOT using an application development
environment which defines error codes consistent
Asynchronous Support Routines
with Microsoft C, you are advised to use the
The asynchronous "database" functions allow Windows Sockets error codes prefixed by "WSA"
applications to request information in an to ensure accurate error code detection.
asynchronous manner. Some network
implementations and/or configurations perform Note that this specification defines a
network based operations to resolve such recommended set of error codes, and lists the
requests. The WSAAsyncGetXByY() functions possible errors which may be returned as a result
allow application developers to request services of each function. It may be the case in some
which would otherwise block the operation of the implementations that other Windows Sockets
whole Windows environment if the standard error codes will be returned in addition to those
Berkeley function were used. The listed, and applications should be prepared to
WSACancelAsyncRequest() function allows an handle errors other than those enumerated under
application to cancel any outstanding each API description. However a Windows
asynchronous request. Sockets implementation must not return any
value which is not enumerated in the table of
legal Windows Sockets errors given in Error
Hooking Blocking Methods Codes
As noted in Blocking/Non blocking & Data
Volatility, Windows Sockets implements
Accessing a Windows Sockets DLL from an
blocking operations in such a way that Windows Intermediate DLL
message processing can continue, which may
result in the application which issued the call A Windows Sockets DLL may be accessed both
receiving a Windows message. In certain directly from an application and through an
situations an application may want to influence or "intermediate" DLL. An example of such an
change the way in which this pseudo-blocking intermediate DLL would be a virtual network
process is implemented. The API layer that supports generalized network
WSASetBlockingHook() provides the ability to functionality for applications and uses Windows
substitute a named routine which the Windows Sockets. Such a DLL could be used by several
Sockets implementation is to use when applications simultaneously, and the DLL must
relinquishing the processor during a "blocking" take special precautions with respect to the
operation. WSAStartup() and WSACleanup() calls to
ensure that these routines are called in the context
of each task that will make Windows Sockets
Error Handling calls. This is because the Windows Sockets DLL
For compatibility with thread-based will need a call to WSAStartup() for each task in
environments, details of API errors are obtained order to set up task-specific data structures, and a
through the WSAGetLastError() API. Although call to WSACleanup() to free any resources
the accepted "Berkeley-Style" mechanism for allocated for the task.
obtaining socket-based network errors is via There are (at least) two ways to accomplish this.
"errno", this mechanism cannot guarantee the The simplest method is for the intermediate DLL
integrity of an error ID in a multi-threaded to have calls similiar to WSAStartup() and
environment. WSAGetLastError() allows you to WSACleanup() that applications call as
retrieve an error code on a per thread basis. appropriate. The DLL would then call
6
WSAStartup() or WSACleanup() from within The current version of Winsock API is Version 2.2.2,
these routines. Another mechanism is for the which has several important features:
intermediate DLL to build a table of task handles, l Multiple Protocol support
which are obtained from the GetCurrentTask() l Transport Protocol Independence: Choose

Windows API, and at each entry point into the protocol by the services they provide
l Multiple Namespaces: Select the protocol you
intermediate DLL check whether WSAStartup() want to resolve hostnames, or locate services
has been called for the current task, then call l Scatter and Gather: Receive and send, to and from
WSAStartup() if necessary. multiple buffers
l Overlapped I/O and Event Objects: Utilize Win32
If a DLL makes a blocking call and does not
paradigms for enhanced throughput
install its own blocking hook, then the DLL l Quality of Service: Negotiate and keep track of
author must be aware that control may be bandwidth per socket
returned to the application either by an l Multipoint and Multicast: Protocol independent
application-installed blocking hook or by the APIs and protocol specific APIs
default blocking hook. Thus, it is possible that the l Conditional Acceptance: Ability to reject or defer
application will cancel the DLL's blocking a connect request before it occurs
l Connect and Disconnect data: For transport
operation via WSACancelBlockingCall(). If this protocols that support it (NOTE: TCP/IP does not)
occurs, the DLL's blocking operation will fail l Socket Sharing: Two or more processes can share
with the error code WSAEINTR, and the DLL a socket handle
must return control to the calling task as quickly l Vendor IDs and a mechanism for vendor
as possible, as the used has likely pressed a extensions: Vendor specific APIs can be added
l Layered Service Providers: The ability to add
cancel or close button and the task has requested
services to existing transport providers
control of the CPU. It is recommended that DLLs
which make blocking calls install their own
blocking hooks with WSASetBlockingHook() to
prevent unforeseen interactions between the
application and the DLL.
Note that this is not necessary for DLLs in
Windows NT because of its different process and
DLL structure. Under Windows NT, the
intermediate DLL could simply call
WSAStartup() in its DLL initialization routine,
which is called whenever a new process which
uses the DLL starts.

The Winsock 2.0 architecture

Winsock (Windows Socket) API is an application
program interface (API) specification that defines how a
windows network application should access underlying
TCP/IP network services.
Winsock performs the following:
· Provides a familiar networking API for
programmers using Windows or UNIX.
· Offers binary compatibility between the Winsock Files
heterogeneous, Windows-based TCP/IP stack and A list of files that Winsock uses to function. The table
utility vendors. lists the files in order of the layer that they support and
· Supports both connection-oriented and gives a brief description of their function.
connectionless protocols. Winsock Files

7
 Winsock
Description
DLLs
Winsock.dll 16-bit Winsock 1.1
Wsock32.dll 32-bit Winsock 1.1
Ws2_32.dll Main Winsock 2.0
WSK applications discover and attach to the WSK
Microsoft extensions to Winsock. subsystem by using a set of WSK registration functions.
Mswsock.dll Mswsock.dll is an API that supplies Applications can use these functions to dynamically
services that are not part of Winsock. detect when the WSK subsystem is available and to
Platform-specific utilities. Ws2help.dll exchange dispatch tables that constitute the provider and
Ws2help.dll supplies operating system–specific code client side implementations of the WSK NPI.
that is not part of Winsock.
What is a DLL?
Wshtcpip.dll Helper for TCP
In a nut shell, a dynamic link library (DLL) is a collection
Wshnetbs.dll Helper for NetBT of small programs, which can be called upon when
Wshirda.dll Helper for IrDA needed by the executable program (EXE) that is running.
The DLL lets the executable communicate with a specific
Wshatm.dll Helper for ATM device such as a printer or may contain source code to do
Wshisn.dll Helper for Netware particular functions.
Wshisotp.dll Helper for OSI transports An example would be if the program (exe) needs to get
the free space of your hard drive. It can call the DLL file
Sfmwshat.dll Helper for Macintosh that contains the function with parameters and a call
Nwprovau.dll Name resolution provider for IPX function. The DLL will then tell the executable the free
space. This allows the executable to be smaller in size and
Rnr20.dll Main name resolution not have to write the function that has already exists.
Winrnr.dll LDAP name resolution This allows any program the information about the free
Msafd.dll Winsock interface to kernel space, without having to write all the source code and it
saves space on your hard drive as well. When a DLL is
Winsock kernel interface to TDI transport used in this fashion are also known as shared files.
Afd.sys
protocols
Advantage of DLL
The advantage of DLL files is that, because they do not
The DLL (Dynamic Link Library) files installed on a get loaded into random access memory (RAM) together
Windows XP system to provide the Winsock API with the main program, space is saved in RAM. When
(Application Programming Interface) to all Winsock and if a DLL file is called, then it is loaded. For example,
applications: you are editing a Microsoft Word document, the printer
l WS2_32.DLL - Providing Winsock 2 32-bit API DLL file does not need to be loaded into RAM. If you
and running on top of a collection of Winsock 2 decide to print the document, then the printer DLL file is
SPIs (Service Provider Interfaces). loaded and a call is made to print.
l WSOCK32.DLL - Providing Winsock 1.1 32-bit Uses fewer resources
API and running on top of the Winsock 2 API. When multiple programs use the same library of
l WINSOCK.DLL - Providing Winsock 1.1 16-bit functions, a DLL can reduce the duplication of code that
API and running on top of the Winsock 2 API. is loaded on the disk and in physical memory.
l mswsock.dll is the DLL (Dynamic Link Library)
file that implements the Winsock 2 SPI (Service Promotes modular architecture
Provider Interface) as the Basic Server Provider in A DLL helps promote developing modular programs.
the Winsock 2 SPI architecture as described in the This helps you develop large programs that require
previous section. multiple language versions or a program that requires
modular architecture.
Eases deployment and installation
Winsock Kernel Architecture When a function within a DLL needs an update or a fix,
the deployment and installation of the DLL does not
The architecture of Winsock Kernel (WSK) is shown in require the program to be relinked with the DLL.
the following diagram. Additionally, if multiple programs use the same DLL, the
8
multiple programs will all benefit from the update or the
fix.
Windows Socket Library Overview
All in all a DLL is an executable file that cannot run on
Socket Functions
its own, it can only run from inside an executable file.
To do load a DLLl file, an executable needs to declare the
The Windows Sockets specification includes the
DLL function. A DLL may have many different functions following Berkeley-style socket routines:
in it. Then when needed the call is made with the required Øaccept() An incoming connection is
parameters. acknowledged and associated with an
The following list describes some of the files that are immediately created socket. The original socket
implemented as DLLs in Windows operating systems: is returned to the listening state.
l ActiveX Controls (.ocx) files Øbind() Assign a local name to an unnamed
An example of an ActiveX control is a calendar socket.
control that lets you select a date from a calendar. Øclosesocket() Remove a socket descriptor from
l Control Panel (.cpl) files the per-process object reference table. Only
An example of a .cpl file is an item that is located blocks if SO_LINGER is set.
in Control Panel. Each item is a specialized DLL. Øconnect() Initiate a connection on the specified
l Device driver (.drv) files
An example of a device driver is a printer driver socket.
that controls the printing to a printer. Øgetpeername() Retrieve the name of the peer
connected to the specified socket descriptor.
DLL dependencies Øgetsockname() Retrieve the current name for
When a program or a DLL uses a DLL function in the specified socket
another DLL, a dependency is created. Therefore, the Øgetsockopt() Retrieve options associated with
program is no longer self-contained, and the program may the specified socket descriptor.
experience problems if the dependency is broken. For Øhtonl() Convert a 32-bit quantity from host byte
example, the program may not run if one of the following order to network byte order.
actions occurs: Øhtons() Convert a 16-bit quantity from host
byte order to network byte order.
l A dependent DLL is upgraded to a new version.
Øinet_addr() Converts a character string
l A dependent DLL is fixed. representing a number in the Internet standard
l A dependent DLL is overwritten with an earlier ``.'' notation to an Internet address value.
version. Øinet_ntoa() Converts an Internet address value
to an ASCII string in ``.'' notation i.e. ``a.b.c.d''.
l A dependent DLL is removed from the computer. Øioctlsocket() Provide control for descriptors.
Ølisten() Listen for incoming connections on a
specified socket.
Internal use of Messages by Windows Øntohl() Convert a 32-bit quantity from network
Sockets Implementations byte order to host byte order.
In order to implement Windows Sockets purely Øntohs() Convert a 16-bit quantity from network
as a DLL, it may be necessary for the DLL to byte order to host byte order.
post messages internally for communication and Ørecv()* Receive data from a connected socket.
timing. This is perfectly legal; however, a Ørecvfrom()* Receive data from either a
Windows Sockets DLL must not post messages connected or unconnected socket.
to a window handle opened by a client Øselect()* Perform synchronous I/O
application except for those messages requested multiplexing.
by the application. A Windows Sockets DLL that Øsend()* Send data to a connected socket.
needs to use messages for its own purposes must Øsendto()* Send data to either a connected or
open a hidden window and post any necessary unconnected socket.
messages to the handle for that window. Øsetsockopt() Store options associated with the
specified socket descriptor.
9
Øshutdown() Shut down part of a full-duplex use of this extended API set is not mandatory for
connection. socket-based programming (with the exception of
Øsocket() Create an endpoint for communication WSAStartup() and WSACleanup()), it is
and return a socket descriptor. recommended for conformance with the
à * The routine can block if acting on a Microsoft Windows programming paradigm.
blocking socket. ØAsynchronous select() Mechanism
Database Functions ØAsynchronous Support Routines
The Windows Sockets specification defines the ØHooking Blocking Methods
following "database" routines. As noted earlier, a ØError Handling
Windows Sockets supplier may choose to ØAccessing a Windows Sockets DLL from an
implement these in a manner which does not Intermediate DLL
depend on local database files. The pointer ØInternal Use of Messages by Windows Sockets
returned by certain database routines such as Implementations
gethostbyname() points to a structure which is ØPrivate API Interfaces
allocated by the Windows Sockets library. The ØWSAAsyncGetHostByAddr() A set of
data which is pointed to is volatile and is good functions which provide asynchronous
only until the next Windows Sockets API call ØWSAAsyncGetHostByName() versions of the
from that thread. Additionally, the application standard Berkeley
must never attempt to modify this structure or to ØWSAAsyncGetProtoByName() getXbyY()
free any of its components. Only one copy of this functions. For example, the
structure is allocated for a thread, and so the ØWSAAsyncGetProtoByNumber()
application should copy any information which it WSAAsyncGetHostByName() function
needs before issuing any other Windows Sockets provides an asynchronous message based
API calls. ØWSAAsyncGetServByName() implementation
Øgethostbyaddr()* Retrieve the name(s) and of the standard Berkeley
address corresponding to a network address. ØWSAAsyncGetServByPort() gethostbyname()
Øgethostname() Retrieve the name of the local function.
host. ØWSAAsyncSelect() Perform asynchronous
Øgethostbyname()* Retrieve the name(s) and version of select()
address corresponding to a host name. ØWSACancelAsyncRequest() Cancel an
Øgetprotobyname()* Retrieve the protocol name outstanding instance of a
and number corresponding to a protocol name. WSAAsyncGetXByY() function.
Øgetprotobynumber()* Retrieve the protocol ØWSACancelBlockingCall() Cancel an
name and number corresponding to a protocol outstanding "blocking" API call
number. ØWSACleanup() Sign off from the underlying
Øgetservbyname()* Retrieve the service name Windows Sockets DLL.
and port corresponding to a service name. ØWSAGetLastError() Obtain details of last
Øgetservbyport()* Retrieve the service name and Windows Sockets API error
port corresponding to a port. ØWSAIsBlocking() Determine if the underlying
à * The routine can block under some Windows Sockets DLL is already blocking an
circumstances. existing call for this thread
ØWSASetBlockingHook() "Hook" the blocking
Microsoft Windows-specific Extension
Functions
method used by the underlying Windows
Sockets implementation
The Windows Sockets specification provides a ØWSASetLastError() Set the error to be returned
number of extensions to the standard set of by a subsequent WSAGetLastError()
Berkeley Sockets routines. Principally, these ØWSAStartup() Initialize the underlying
extended APIs allow message-based, Windows Sockets DLL.
asynchronous access to network events. While ØWSAUnhookBlockingHook() Restore the
10
original blocking function

11