throbber
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-Page 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-Page 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-Page 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-Page 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-Page 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-Page 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-Page 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-Page 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-Page 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-Page 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-Page 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-Page 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-Page 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 access

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket