Windows Sockets
`
`Page 1 of 124
`
` Windows Sockets
`An Open Interface for
`Network Programming under
`Microsoft Windows
`Version 1.1
`20 January 1993
`
`Note
`This HTML version of the Windows Socket 1.1 Specification is provided by Mark Towfiq. It may be
`freely redistributed, either as provided or in modified form. Winsock providers may integrate it into their
`product documentation without incurring any obligation.
`Acknowledgements
`I am indebted and thankful to:
`
`· Joel Golberger of InfoMagic, Inc. for the work he did on the Windows Help version of the
`Windows Sockets Specification. I used his .RTF file as the source file for this document.
`· Chris Hector of Cray Research Inc. for his package rtftohtml, which was used to generate this
`document.
`
`Mark Towfiq (towfiq@East.Sun.Com)
`
`Table of Contents
`
`· Authors and Copyright
`· Acknowledgments
`· Introduction
`(cid:127) What is Windows Sockets
`(cid:127) Berkeley Sockets
`(cid:127) Microsoft Windows and Windows-specific extensions
`(cid:127) The Status of this Specification
`(cid:127) Revision History
`† Windows Sockets Version 1.0
`† Windows Sockets Version 1.1
`· Programming with Sockets
`(cid:127) Windows Sockets Stack Installation Checking
`(cid:127) Sockets
`† Basic concepts
`† Client-server model
`
`http://www.sockets.com/winsock.htm
`
`6/15/2013
`
`New Bay Capital, LLC-EX.1005-1 of 124
`
`

`
`Windows Sockets
`
`Page 2 of 124
`
`† Out-of-band data
`† Broadcasting
`(cid:127) Byte Ordering
`(cid:127) Socket Options
`(cid:127) Database Files
`(cid:127) Deviation from Berkeley Sockets
`† socket data type and error values
`† select() and FD_*
`† Error codes - errno, h_errno & WSAGetLastError()
`† Pointers
`† Renamed functions
`† Blocking routines & EINPROGRESS
`† Maximum number of sockets supported
`† Include files
`† Return values on API failure
`(cid:127) Raw Sockets
`(cid:127) Windows Sockets in Multithreaded Versions of Windows
`· Socket Library Overview
`(cid:127) Socket Functions
`† Blocking/Non blocking & Data Volatility
`(cid:127) Database Functions
`(cid:127) Microsoft Windows-specific Extension Functions
`† Asynchronous select() Mechanism
`† Asynchronous Support Routines
`† Hooking Blocking Methods
`† Error Handling
`† Accessing a Windows Sockets DLL from an Intermediate DLL
`† Internal use of Messages by Windows Sockets Implementations
`† Private API Interfaces
`· Socket Library Reference
`(cid:127) Socket Routines
`† accept()
`† bind()
`† closesocket()
`† connect()
`† getpeername()
`† getsockname()
`† getsockopt()
`† htonl()
`† htons()
`† inet_addr()
`† inet_ntoa()
`† ioctlsocket()
`† listen()
`† ntohl()
`† ntohs()
`† recv()
`† recvfrom()
`† select()
`† send()
`† sendto()
`† setsockopt()
`
`http://www.sockets.com/winsock.htm
`
`6/15/2013
`
`New Bay Capital, LLC-EX.1005-2 of 124
`
`

`
`Windows Sockets
`
`Page 3 of 124
`
`† shutdown()
`† socket()
`(cid:127) Database Routines
`† gethostbyaddr()
`† gethostbyname()
`† gethostname()
`† getprotobyname()
`† getprotobynumber()
`† getservbyname()
`† GetServByPort()
`(cid:127) Microsoft Windows-specific Extensions
`† WSAAsyncGetHostByAddr()
`† WSAAsyncGetHostByName()
`† WSAAsyncGetProtoByName()
`† WSAAsyncGetProtoByNumber()
`† WSAAsyncGetServByName()
`† WSAAsyncGetServByPort()
`† WSAAsyncSelect()
`† WSACancelAsyncRequest()
`† WSACancelBlockingCall()
`† WSACleanup()
`† WSAGetLastError()
`† WSAIsBlocking()
`† WSASetBlockingHook()
`† WSASetLastError()
`† WSAStartup()
`† WSAUnhookBlockingHook()
`· Appendices
`(cid:127) Error Codes and Header Files
`† Error Codes
`† Header Files
`† Berkeley Header Files
`† Windows Sockets Header File - winsock.h
`(cid:127) Notes for Windows Sockets Suppliers
`† Introduction
`† Windows Sockets Components
`† Development Components
`† Run Time Components
`† Multithreadedness and blocking routines.
`† Database Files
`† FD_ISSET
`† Error Codes
`† DLL Ordinal Numbers
`† Validation Suite
`(cid:127) For Further Reference
`(cid:127) Background Information
`† Origins of Windows Sockets
`† Legal Status of Windows Sockets
`† The Story Behind the Windows Sockets Icon
`
`http://www.sockets.com/winsock.htm
`
`6/15/2013
`
`New Bay Capital, LLC-EX.1005-3 of 124
`
`

`
`Windows Sockets
`
`Page 4 of 124
`
`Authors and Copyright
`Martin Hall
`MarkTowfiq
`Geoff Arnold
`David Treadwell
`Henry Sanders
`Copyright (c) 1992 by Martin Hall, Mark Towfiq
`Geoff Arnold, David Treadwell and Henry Sanders
`
`All rights reserved.
`
`This document may be freely redistributed in any form, electronic or otherwise, provided that it is
`distributed in its entirety and that the copyright and this notice are included. Comments or questions may
`be submitted via electronic mail to WinSock@MailBag.Intel.Com. Requests to be added to the Windows
`Sockets mailing list should be addressed to MajorDomo@MailBag.Intel.Com. This specification,
`archives of the mailing list, and other information on Windows Sockets are available via anonymous FTP
`from the host SunSite.UNC.Edu, directory /pub/micro/pc-stuff/ms-windows/winsock. Questions about
`products conforming to this specification should be addressed to the vendors of the products.
`
`Acknowledgments
`
`The authors would like to thank their companies for allowing them the time and resources to make this
`specification possible: JSB Corporation, Microdyne Corporation, FTP Software, Sun Microsystems, and
`Microsoft Corporation.
`
`Special thanks should also be extended to the other efforts contributing to the success of Windows
`Sockets. The original draft was heavily influenced by existing specifications offered and detailed by JSB
`Corporation and NetManage, Inc. The "version 1.0 debate" hosted by Microsoft in Seattle allowed many
`of the members of the working group to hash out final details for 1.0 vis-a-vis.
`
`Sun Microsystems was kind enough to allow first time implementors to "plug and play" beta software
`during the first Windows Sock-A-Thon of Windows Sockets applications and implementations at Interop
`Fall '92. Microsoft has shared WSAT (the Windows Sockets API Tester) with other Windows Sockets
`implementors as a standard Windows Sockets test suite to aid in testing their implementations. Finally,
`Sun Microsystems and FTP Software plan to host the Windows Sock-A-Thon II in Boston February '93.
`
`Without the contributions of the individuals and corporations involved in the working group, Windows
`Sockets would never have been as thoroughly reviewed and completed as quickly. In just one year,
`several competitors in the networking business developed a useful specification with something to show
`for it! Many thanks to all which participated, either in person or on e-mail to the Windows Sockets effort.
`The authors would like to thank everyone who participated in any way, and apologize in advance for
`anyone we have omitted.
`
`http://www.sockets.com/winsock.htm
`
`6/15/2013
`
`New Bay Capital, LLC-EX.1005-4 of 124
`
`

`
`Windows Sockets
`
`List of contributors:
`
`Page 5 of 124
`
`JSB Corporation
`(Chairman)
`Martin Hall
`martinh@jsbus.com
`(Coordinator)Microdyne Corporation
`Mark Towfiq
`towfiq@microdyne.com
`Geoff Arnold (Editor 1.0)
`Sun Microsystems
`geoff@east.sun.com
`David Treadwell(Editor 1.1)
`Microsoft Corporation
`davidtr@microsoft.com
`Henry Sanders
`Microsoft Corporation
`henrysa@microsoft.com
`J. Allard
`Microsoft Corporation
`jallard@microsoft.com
`Chris Arap-Bologna
`Distinct
`chris@distinct.com
`Larry Backman
`FTP Software
`backman@ftp.com
`Alistair Banks
`Microsoft Corporation
`alistair@microsoft.com
`Rob Barrow
`JSB Corporation
`robb@jsb.co.uk
`Carl Beame
`Beame & Whiteside
`beame@mcmaster,ca
`Dave Beaver
`Microsoft Corporation
`dbeaver@microsoft.com
`Amatzia BenArtzi
`NetManage, Inc.
`amatzia@netmanage.com
`Mark Beyer
`Ungermann-Bass
`mbeyer@ub.com
`Nelson Bolyard
`Silicon Graphics, Inc.
`nelson@sgi.com
`Pat Bonner
`Hewlett-Packard
`p_bonner@cnd.hp.com
`Derek Brown
`FTP Software
`db@wco.ftp.com
`Malcolm Butler
`ICL
`mcab@oasis.icl.co.uk
`Mike Calbaum
`Frontier Technologies
`mike@frontiertech.com
`Isaac Chan
`Microsoft Corporation
`isaacc@microsoft.com
`Khoji Darbani
`Informix
`khoji@informix.com
`Nestor Fesas
`Hughes LAN Systems
`nestor@hls.com
`Karanja Gakio
`FTP Software
`karanja@ftp.com
`Vikas Garg
`Distinct
`vikas@distinct.com
`Gary Gere
`Gupta
`ggere@gupta.com
`Jim Gilroy
`Microsoft Corporation
`jamesg@microsoft.com
`Bill Hayes
`Hewlett-Packard
`billh@hpchdpc.cnd.hp.com
`Paul Hill
`MIT
`pbh@athena.mit.edu
`Tmima Koren
`NetManage, Inc.
`tmima@netmanage.com
`Hoek Law
`law@dcc.tti.com
`Graeme Le Roux
`Moresdawn P/L
`-
`Kevin Lewis
`Novell
`kevinl@novell.com
`Roger Lin
`3Com
`roger_lin@3mail.3com.com
`Terry Lister
`Hewlett-Packard
`tel@cnd.hp.com
`Jeng Long Jiang
`Wollongong
`long@twg.com
`Lee Murach
`Network Researchlee@nrc.com
`Pete Ostenson
`Microsoft Corporation
`peteo@microsoft.com
`David Pool
`Spry, Inc.
`dave@spry.com
`Bob Quinn
`FTP Software
`rcq@ftp.com
`Glenn Reitsma
`Hughes LAN Systems
`glennr@hls.com
`Brad Rice
`Age
`rice@age.com
`Allen Rochkind
`3Com
`-
`jrosen@vnet.ibm.com
`Jonathan Rosen
`IBM
`Steve Stokes
`Novell
`stoke@novell.com
`Joseph Tsai
`3Com
`joe_tsai@3mail.3com.com
`James Van Bokkelen
`FTP Software
`jbvb@ftp.com
`Miles Wu
`Wollongong
`wu@twg.com
`Boris Yanovsky
`NetManage, Inc.
`boris@netmanage.com
`
`Citicorp
`
`Introduction
`
`http://www.sockets.com/winsock.htm
`
`6/15/2013
`
`New Bay Capital, LLC-EX.1005-5 of 124
`
`

`
`Windows Sockets
`
`Page 6 of 124
`
`What is Windows Sockets
`The Windows Sockets specification defines a network programming interface for Microsoft Windows
`which is based on the "socket" paradigm popularized in the Berkeley Software Distribution (BSD) from
`the University of California at Berkeley. It encompasses both familiar Berkeley socket style routines and
`a set of Windows-specific extensions designed to allow the programmer to take advantage of the
`message-driven nature of Windows.
`
`The Windows Sockets Specification is intended to provide a single API to which application developers
`can program and multiple network software vendors can conform. Furthermore, in the context of a
`particular version of Microsoft Windows, it defines a binary interface (ABI) such that an application
`written to the Windows Sockets API can work with a conformant protocol implementation from any
`network software vendor. This specification thus defines the library calls and associated semantics to
`which an application developer can program and which a network software vendor can implement.
`
`Network software which conforms to this Windows Sockets specification will be considered "Windows
`Sockets Compliant". Suppliers of interfaces which are "Windows Sockets Compliant" shall be referred to
`as "Windows Sockets Suppliers". To be Windows Sockets Compliant, a vendor must implement 100% of
`this Windows Sockets specification.
`
`Applications which are capable of operating with any "Windows Sockets Compliant" protocol
`implementation will be considered as having a "Windows Sockets Interface" and will be referred to as
`"Windows Sockets Applications".
`
`This version of the Windows Sockets specification defines and documents the use of the API in
`conjunction with the Internet Protocol Suite (IPS, generally referred to as TCP/IP). Specifically, all
`Windows Sockets implementations support both stream (TCP) and datagram (UDP) sockets.
`
`While the use of this API with alternative protocol stacks is not precluded (and is expected to be the
`subject of future revisions of the specification), such usage is beyond the scope of this version of the
`specification.
`
`Berkeley Sockets
`The Windows Sockets Specification has been built upon the Berkeley Sockets programming model which
`is the de facto standard for TCP/IP networking. It is intended to provide a high degree of familiarity for
`programmers who are used to programming with sockets in UNIX and other environments, and to
`simplify the task of porting existing sockets-based source code. The Windows Sockets API is consistent
`with release 4.3 of the Berkeley Software Distribution (4.3BSD).
`
`Portions of the Windows Sockets specification are derived from material which is Copyright (c) 1982-
`1986 by the Regents of the University of California. All rights are reserved. The Berkeley Software
`License Agreement specifies the terms and conditions for redistribution.
`
`Microsoft Windows and Windows-specific extensions
`
`http://www.sockets.com/winsock.htm
`
`6/15/2013
`
`New Bay Capital, LLC-EX.1005-6 of 124
`
`

`
`Windows Sockets
`
`Page 7 of 124
`
`This API is intended to be usable within all implementations and versions of Microsoft Windows from
`Microsoft Windows Version 3.0 onwards. It thus provides for Windows Sockets implementations and
`Windows Sockets applications in both 16 and 32 bit operating environments.
`
`Windows Sockets makes provisions for multithreaded Windows processes. A process contains one or
`more threads of execution. In the Windows 3.1 non-multithreaded world, a task corresponds to a process
`with a single thread. All references to threads in this document refer to actual "threads" in multithreaded
`Windows environments. In non multithreaded environments (such as Windows 3.0), use of the term
`thread refers to a Windows process.
`
`The Microsoft Windows extensions included in Windows Sockets are provided to allow application
`developers to create software which conforms to the Windows programming model. It is expected that
`this will facilitate the creation of robust and high-performance applications, and will improve the
`cooperative multitasking of applications within non-preemptive versions of Windows. With the exception
`of WSAStartup() and WSACleanup() their use is not mandatory.
`
`The Status of this Specification
`Windows Sockets is an independent specification which was created and exists for the benefit of
`application developers and network vendors and, indirectly, computer users. Each published (non-draft)
`version of this specification represents a fully workable API for implementation by network vendors and
`programming use by application developers. Discussion of this specification and suggested
`improvements continue and are welcomed. Such discussion occurs mainly via the Internet electronic mail
`forum winsock@microdyne.com. Meetings of interested parties occur on an irregular basis. Details of
`these meetings are publicized to the electronic mail forum.
`
`Revision History
`
`Windows Sockets Version 1.0
`
`Windows Sockets Version 1.0 represented the results of considerable work within the vendor and user
`community as discussed in " Origins of Windows Sockets". This version of the specification was released
`in order that network software suppliers and application developers could begin to construct
`implementations and applications which conformed to the Windows Sockets standard.
`
`Windows Sockets Version 1.1
`
`Windows Sockets Version 1.1 follows the guidelines and structure laid out by version 1.0, making
`changes only where absolutely necessary as indicated by the experiences of a number of companies that
`created Windows Sockets implementations based on the version 1.0 specification. Version 1.1 contains
`several clarifications and minor fixes to version 1.0. Additionally, the following more significant changes
`were incorporated into version 1.1:
`
`http://www.sockets.com/winsock.htm
`
`6/15/2013
`
`New Bay Capital, LLC-EX.1005-7 of 124
`
`

`
`Windows Sockets
`
`Page 8 of 124
`
`Inclusion of the gethostname() routine to simplify retrieval of the host's name and address.
`
`Definition of DLL ordinal values below 1000 as reserved for Windows Sockets and ordinals above
`1000 as unrestricted. This allows Windows Sockets vendors to include private interfaces to their
`DLLs without risking that the ordinals choosen will conflict with a future version of Windows
`Sockets.
`
`Addition of a reference count to WSAStartup() and WSACleanup(), requiring correspondences
`between the calls. This allows applications and third-party DLLs to make use of a Windows
`Sockets implementation without being concerned about the calls to these APIs made by the other.
`
`Change of return type of inet_addr() from struct in_addr to unsigned long. This was required due
`to different handling of four-byte structure returns between the Microsoft and Borland C compilers.
`
`Change of WSAAsyncSelect() semantics from "edge-triggerred" to "level-triggerred". The level-
`triggerred semantics significantly simplify an application's use of this routine.
`
`Change the ioctlsocket() FIONBIO semantics to fail if a WSAAsyncSelect() call is outstanding on
`the socket.
`
`Addition of the TCP_NODELAY socket option for RFC 1122 conformance.
`
`Programming with Sockets
`
`Windows Sockets Stack Installation Checking
`To detect the presence of one (or many) Windows Sockets implementations on a system, an application
`which has been linked with the Windows Sockets Import Library may simply call the WSAStartup()
`routine. If an application wishes to be a little more sophisticated it can examine the $PATH environment
`variable and search for instances of Windows Sockets implementations (WINSOCK.DLL). For each
`instance it can issue a LoadLibrary() call and use the WSAStartup() routine to discover implementation
`specific data.
`
`This version of the Windows Sockets specification does not attempt to address explicitly the issue of
`multiple concurrent Windows Sockets implementations. Nothing in the specification should be
`interpreted as restricting multiple Windows Sockets DLLs from being present and used concurrently by
`one or more Windows Sockets applications.
`
`For further details of where to obtain Windows Sockets components, see " Windows Sockets
`Components".
`
`Sockets
`
`http://www.sockets.com/winsock.htm
`
`6/15/2013
`
`New Bay Capital, LLC-EX.1005-8 of 124
`
`

`
`Windows Sockets
`
`Page 9 of 124
`
`The following material is derived from the document "An Advanced 4.3BSD Interprocess
`Communication Tutorial" by Samuel J. Leffler, Robert S. Fabry, William N. Joy, Phil Lapsley, Steve
`Miller, and Chris Torek.
`
`Basic concepts
`
`The basic building block for communication is the socket. A socket is an endpoint of communication to
`which a name may be bound. Each socket in use has a type and an associated process. Sockets exist
`within communication domains. A communication domain is an abstraction introduced to bundle
`common properties of threads communicating through sockets. Sockets normally exchange data only
`with sockets in the same domain (it may be possible to cross domain boundaries, but only if some
`translation process is performed). The Windows Sockets facilities support a single communication
`domain: the Internet domain, which is used by processes which communicate using the Internet Protocol
`Suite. (Future versions of this specification may include additional domains.)
`
`Sockets are typed according to the communication properties visible to a user. Applications are presumed
`to communicate only between sockets of the same type, although there is nothing that prevents
`communication between sockets of different types should the underlying communication protocols
`support this.
`
`Two types of sockets currently are available to a user. A stream socket provides for the bi-directional,
`reliable, sequenced, and unduplicated flow of data without record boundaries.
`
`A datagram socket supports bi-directional flow of data which is not promised to be sequenced, reliable,
`or unduplicated. That is, a process receiving messages on a datagram socket may find messages
`duplicated, and, possibly, in an order different from the order in which it was sent. An important
`characteristic of a datagram socket is that record boundaries in data are preserved. Datagram sockets
`closely model the facilities found in many contemporary packet switched networks such as Ethernet.
`
`Client-server model
`
`The most commonly used paradigm in constructing distributed applications is the client/server model. In
`this scheme client applications request services from a server application. This implies an asymmetry in
`establishing communication between the client and server.
`
`The client and server require a well-known set of conventions before service may be rendered (and
`accepted). This set of conventions comprises a protocol which must be implemented at both ends of a
`connection. Depending on the situation, the protocol may be symmetric or asymmetric. In a symmetric
`protocol, either side may play the master or slave roles. In an asymmetric protocol, one side is immutably
`recognized as the master, with the other as the slave. An example of a symmetric protocol is the TELNET
`protocol used in the Internet for remote terminal emulation. An example of an asymmetric protocol is the
`Internet file transfer protocol, FTP. No matter whether the specific protocol used in obtaining a service is
`symmetric or asymmetric, when accessing a service there is a ``client process'' and a ``server process''.
`
`A server application normally listens at a well-known address for service requests. That is, the server
`process remains dormant until a connection is requested by a client's connection to the server's address.
`At such a time the server process ``wakes up'' and services the client, performing whatever appropriate
`
`http://www.sockets.com/winsock.htm
`
`6/15/2013
`
`New Bay Capital, LLC-EX.1005-9 of 124
`
`

`
`Windows Sockets
`
`Page 10 of 124
`
`actions the client requests of it. While connection-based services are the norm, some services are based
`on the use of datagram sockets.
`
`Out-of-band data
`
`Note: The following discussion of out-of-band data, also referred to as TCP Urgent data, follows the
`model used in the Berkeley software distribution. Users and implementors should be aware of the fact
`that there are at present two conflicting interpretations of RFC 793 (in which the concept is introduced),
`and that the implementation of out-of-band data in the Berkeley Software Distribution does not conform
`to the Host Requirements laid down in RFC 1122. To minimize interoperability problems, applications
`writers are advised not to use out-of-band data unless this is required in order to interoperate with an
`existing service. Windows Sockets suppliers are urged to document the out-of-band semantics (BSD or
`RFC 1122) which their product implements. It is beyond the scope of this specification to mandate a
`particular set of semantics for out-of-band data handling.
`
`The stream socket abstraction includes the notion of ``out of band'' data. Out-of-band data is a logically
`independent transmission channel associated with each pair of connected stream sockets. Out-of-band
`data is delivered to the user independently of normal data. The abstraction defines that the out-of-band
`data facilities must support the reliable delivery of at least one out-of-band message at a time. This
`message may contain at least one byte of data, and at least one message may be pending delivery to the
`user at any one time. For communications protocols which support only in-band signaling (i.e. the urgent
`data is delivered in sequence with the normal data), the system normally extracts the data from the normal
`data stream and stores it separately. This allows users to choose between receiving the urgent data in
`order and receiving it out of sequence without having to buffer all the intervening data. It is possible to
```peek'' at out-of-band data.
`
`An application may prefer to process out-of-band data "in-line", as part of the normal data stream. This is
`achieved by setting the socket option SO_OOBINLINE (see setsockopt()). In this case, the application
`may wish to determine whether any of the unread data is "urgent" (the term usually applied to in-line out-
`of-band data). To facilitate this, the Windows Sockets implementation will maintain a logical "mark" in
`the data stream to indicate the point at which the out-of-band data was sent. An application can use the
`SIOCATMARK ioctlsocket() command to determine whether there is any unread data preceding the
`mark. For example, it might use this to resynchronize with its peer by ensuring that all data up to the
`mark in the data stream is discarded when appropriate.
`
`The WSAAsyncSelect() routine is particularly well suited to handling notification of the presence of out-
`of-band-data.
`
`Broadcasting
`
`By using a datagram socket, it is possible to send broadcast packets on many networks supported by the
`system. The network itself must support broadcast: the system provides no simulation of broadcast in
`software. Broadcast messages can place a high load on a network, since they force every host on the
`network to service them. Consequently, the ability to send broadcast packets has been limited to sockets
`which are explicitly marked as allowing broadcasting. Broadcast is typically used for one of two reasons:
`it is desired to find a resource on a local network without prior knowledge of its address, or important
`functions such as routing require that information be sent to all accessible neighbors.
`
`http://www.sockets.com/winsock.htm
`
`6/15/2013
`
`New Bay Capital, LLC-EX.1005-10 of 124
`
`

`
`Windows Sockets
`
`Page 11 of 124
`
`The destination address of the message to be broadcast depends on the network(s) on which the message
`is to be broadcast. The Internet domain supports a shorthand notation for broadcast on the local network,
`the address INADDR_BROADCAST. Received broadcast messages contain the senders address and
`port, as datagram sockets must be bound before use.
`
`Some types of network support the notion of different types of broadcast. For example, the IEEE 802.5
`token ring architecture supports the use of link-level broadcast indicators, which control whether
`broadcasts are forwarded by bridges. The Windows Sockets specification does not provide any
`mechanism whereby an application can determine the type of underlying network, nor any way to control
`the semantics of broadcasting.
`
`Byte Ordering
`The Intel byte ordering is like that of the DEC VAX, and therefore differs from the Internet and 68000-
`type processor byte ordering. Thus care must be taken to ensure correct orientation.
`
`Any reference to IP addresses or port numbers passed to or from a Windows Sockets routine must be in
`network order. This includes the IP address and port fields of a struct sockaddr_in (but not the
`sin_family field).
`
`Consider an application which normally contacts a server on the TCP port corresponding to the "time"
`service, but which provides a mechanism for the user to specify that an alternative port is to be used. The
`port number returned by getservbyname() is already in network order, which is the format required
`constructing an address, so no translation is required. However if the user elects to use a different port,
`entered as an integer, the application must convert this from host to network order (using the htons()
`function) before using it to construct an address. Conversely, if the application wishes to display the
`number of the port within an address (returned via, e.g., getpeername()), the port number must be
`converted from network to host order (using ntohs()) before it can be displayed.
`
`Since the Intel and Internet byte orders are different, the conversions described above are unavoidable.
`Application writers are cautioned that they should use the standard conversion functions provided as part
`of the Windows Sockets API rather than writing their own conversion code, since future implementations
`of Windows Sockets are likely to run on systems for which the host order is identical to the network byte
`order. Only applications which use the standard conversion functions are likely to be portable.
`
`Socket Options
`The socket options supported by Windows Sockets are listed in the pages describing setsockopt() and
`getsockopt(). AWindows Sockets implementation must recognize all of these options, and (for
`getsockopt()) return plausible values for each. The default value for each option is shown in the following
`table.
`Default
`Meaning
`Type
`Value
`------------------------------------------------------------------------
`SO_ACCEPTCON
`BOOL
`Socket is listen()ing.
`FALSE unless a listen()
`has been performed
`
`Note
`
`http://www.sockets.com/winsock.htm
`
`6/15/2013
`
`New Bay Capital, LLC-EX.1005-11 of 124
`
`

`
`Windows Sockets
`
`Page 12 of 124
`
`SO_BROADCAST
`
`BOOL
`
`Socket is configured
`for the transmission of
`broadcast messages.
`
`FALSE
`
`SO_DEBUGBOOL
`
`Debugging is enabled. FALSE
`
`(i)
`
`SO_DONTLINGERBOOL
`
`If true, the SO_LINGERTRUE
`option is disabled..
`
`SO_DONTROUTE
`
`BOOL
`
`Routing is disabled.
`
`FALSE
`
`(i)
`
`SO_ERRORint
`
`Retrieve error status
`and clear.
`
`0
`
`SO_KEEPALIVE
`
`BOOL
`
`Keepalives are being
`sent.
`
`FALSE
`
`SO_LINGER
`
`struct lingerReturns the current
`FAR *
`linger options.
`
`l_onoff is 0
`
`SO_OOBINLINE
`
`BOOL
`
`SO_RCVBUF
`
`int
`
`SO_REUSEADDR
`
`BOOL
`
`Out-of-band data is
`being received in the
`normal data stream.
`
`FALSE
`
`Buffer size for
`receives
`
`Implementation(i)
`dependant.
`
`The address to which
`this socket is bound
`can be used by others.
`
`FALSE
`
`SO_SNDBUF
`
`int
`
`Buffer size for sendsImplementation(i)
`dependant.
`
`SO_TYPE
`
`int
`
`The type of the socketAs created
`
`http://www.sockets.com/winsock.htm
`
`6/15/2013
`
`New Bay Capital, LLC-EX.1005-12 of 124
`
`

`
`Windows Sockets
`
`Page 13 of 124
`
`TCP_NODELAY
`
`BOOL
`
`Notes:
`
`(e.g. SOCK_STREAM).
`
`via socket()
`
`Disables the Nagle
`algorithm for send
`coalescing.
`
`Implementation
`dependant.
`
`(i) An implementation may silently ignore this option on setsockopt() and return a constant value for
`getsockopt(), or it may accept a value for setsockopt() and return the corresponding value in getsockopt()
`without using the value in any way.
`
`Database Files
`The getXbyY() and WSAAsyncGetXByY() classes of routines are provided for retrieving network
`specific information. The getXbyY() routines were originally designed (in the first Berkeley UNIX
`releases) as mechanisms for looking up information in text databases. Although the information may be
`retrieved by the Windows Sockets implementation in different ways, a Windows Sockets application
`requests such information in a consistent manner through either the getXbyY() or the
`WSAAsyncGetXByY() class of routines.
`
`Deviation from Berkeley Sockets
`There are a few limited instances where the Windows Sockets API has had to divert from strict adherence
`to the Berkeley conventions, usually because of difficulties of implementation in a Windows
`environment.
`
`socket data type and error values
`
`select() and FD_*
`
`Error codes -- errno, h_errno & WSAGetLastError()
`
`Pointers
`
`Renamed functions
`
`Blocking routines & EINPROGRESS
`
`Maximum number of sockets supported
`
`Include files
`
`Return values on API failure
`
`http://www.sockets.com/winsock.htm
`
`6/15/2013
`
`New Bay Capital, LLC-EX.1005-13 of 124
`
`

`
`Windows Sockets
`
`Page 14 of 124
`
`socket data type and error values
`
`A new data type, SOCKET, has been defined. The definition of this type was necessary for future
`enhancements to the Windows Sockets specification, such as being able to use sockets as file handles in
`Windows NT. Definition of this type also facilitates porting of applications to a Win/32 environment, as
`the type will automatically be promoted from 16 to 32 bits.
`
`In UNIX, all handles, including socket handles, are small, non-negative intergers, and some applications
`make assumptions that this will be true. Windows Sockets handles have no restrictions, other than that
`the value INVALID_SOCKET is not a valid socket. Socket handles may take any value in the range 0 to
`INVALID_SOCKET-1.
`
`Because the SOCKET type is unsigned, compiling existing source code from, for example, a UNIX
`environment may lead to compiler warnings about signed/unsigned data type mismatches.
`
`This means, for example, that checking forerrors when the socket() and accept() routines return should
`not be done by comparing the return value with -1, or seeing if the value is negative (both common, and
`legal, approaches in BSD). Instead, an application should use the manifest constant INVALID_SOCKET
`as defined in winsock.h. For example:
`
`TYPICAL BSD STYLE:
`
`s = socket(...);
`if (s == -1)
`{...}
`
`/* or s < 0 */
`
`PREFERRED STYLE:
`
`s = socket(...);
`if (s == INVALID_SOCKET)
`{...}
`
`select() and FD_*
`
`Because a SOCKET is no longer represented by the UNIX-style "small non-negative integer", the
`implementation of the select() function was changed in the Windows Sockets API. Each set of descriptors
`is still represented by the fd_set type, but instead of being stored as a bitmask the set is implemented as
`an array of SOCKETs.. To avoid potential problems, applications must adhere to the use of the FD_XXX
`macros to set, initialize, clear, and check the fd_set structures.
`
`Error codes -- errno, h_errno & WSAGetLastError()
`
`Error codes set by the Windows Sockets implementation are NOT made available via the errno variable.
`Additionally, for the getXbyY() class of functions, error codes are NOT made available via the h_errno
`variable. Instead, error codes are accessed by using the WSAGetLastError() API. This function is
`
`http://