Multiprotocol Support for Windows Sockets 
Article ID: Q125704
Revision Date: 29-SEP-1995
 
The information in this article applies to:

 - Microsoft Win32 Software Development Kit (SDK)



SUMMARY 
The Windows Sockets (WinSock) API is based on the Berkeley Sockets progamming model, the standard interface for TCP/IP network programming on Windows. However, the WinSock implementations for Windows NT and Windows 95 include support for additional network transports. Here are the network transports supported by Microsoft WinSock implementations, listed by platform. For convenience, the headers and libraries required for application development are also listed. 

Platform      Transport                Header*                  Lib 
Windows NT    TCP/IP                   WINSOCK.H               WSOCK32.LIB
              IPX/SPX                  WSIPX.H, WSNWLINK.H     ""
              NetBEUI (via NetBIOS)    WSNETBS.H               ""
              Appletalk                ATALKWSH.H              ""
              ISO/TP4                  WSHISOTP.H              ""

Windows 95    TCP/IP                   WINSOCK.H               ""
              IPX/SPX                  WSIPX.H, WSNWLINK.H     ""



Windows for


Workgroups
version 3.11  TCP/IP                   WINSOCK.H               WINSOCK.LIB


* WINSOCK.H is required for all platforms and transports, in addition to 
  other header files.



MORE INFORMATION 
The Windows Sockets API provides a uniform interface to multiple network transports and shields the programmer from most transport level ideosyncracies. However, WinSock does not eliminate the need to learn the basics of the transport protocol used. In particular, the programmer should be familiar with the following aspects of any transport protocol used with Windows Sockets: 

1. Addressing.

   Each transport uses different address format. For example, the IP
   socket address structures looks like this:

   /*
    * Socket address, internet style.
    */
   struct sockaddr_in
   {
      short   sin_family;
      u_short sin_port;
      struct  in_addr sin_addr;
      char    sin_zero[8];
   };

   struct in_addr
   {
      union
      {
         struct { u_char s_b1,s_b2,s_b3,s_b4; } S_un_b;
         struct { u_short s_w1,s_w2; } S_un_w;
         u_long S_addr;
      } S_un;
   }

   In contrast, the IPX address structure looks like this:

   typedef struct sockaddr_ipx
   {
      short sa_family;
      char  sa_netnum[4];
      char  sa_nodenum[6];
      unsigned short sa_socket;
   } SOCKADDR_IPX;

2. Connection-Oriented vs. Connectionless Transport.

   In a connection-oriented transport protocol such as TCP or SPX,
   applications are required to establish a virtual circuit before data
   transfer can take place. The following sequences of WinSock functions
   are required at minimum to establish a virtual circuit:

   Server     Client
   ------------------
   socket     socket
   bind       connect
   listen
   accept

   After the virtual circuit is established, the send() and recv()
   functions are used to transfer data.

   In a connectionless transport, a virtual circuit is not established.
   Both the client and server exchange data by binding a socket and
   calling sendto() or recvfrom().

3. Virtual circuit termination semantics.

4. Message Oriented vs. Stream-Oriented.

   See the Win32 SDK online documentation for information on these topics.

5. Expedited data delivery.

   This is data that has been earmarked by the application as urgent data,
   and will be sent by the transport as quickly as possible. Not all
   transports support this feature. The Windows Sockets API provides the
   ability to request expedited data delivery via the MSG_OOB flag in the
   send() function.

6. Broadcasts.

   Here is an extract from the Win32 SDK online documentation:

   "Most connectionless transport protocols support broadcasts in the
   same fashion, in which any bound socket can send a broadcast if the
   SO_BROADCAST option is set, and broadcasts sent to the appropriate
   local endpoint are received without any additional work on the part
   of the application. NetBIOS transport protocols, however, handle
   broadcasts somewhat differently. In order to receive broadcasts, an
   application must bind to the NetBIOS broadcast address, which is an
   asterisk ("*") followed by 15 blank spaces (ASCII character 0x20).
   This means two things: A socket must be specially bound to receive
   broadcasts, and applications cannot depend on receiving broadcasts
   intended only for a specific application, since all NetBIOS broadcasts
   are delivered to this address. In other protocols such as
   UDP/IP and IPX, broadcasts are delivered to a socket only if the
   broadcast was sent to the same port to which the socket was bound."


For more information on any of the above topics, please see the Win32 SDK online documentation. 

Additional reference words: 4.00


KBCategory: kbnetwork
KBSubcategory: NtwkWinsock


 

THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS
PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND.  MICROSOFT DISCLAIMS
ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES
OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.  IN NO
EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR
ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL,
CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF
MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.  SOME STATES DO NOT ALLOW THE EXCLUSION
OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES
SO THE FOREGOING LIMITATION MAY NOT APPLY.

Copyright Microsoft Corporation 1995.
