The Basic Structures

Although the Windows Sockets specification contains about a dozen different structures, application developers will quickly become familiar with a few that are required by nearly all Windows Sockets applications.


struct sockaddr {
        u_short sa_family;              
        char    sa_data[14];
};
struct sockaddr_in {
        short   sin_family;
        u_short sin_port;
        struct  in_addr sin_addr;
        char    sin_zero[8];
};

The sockaddr structure is used by Windows Sockets to specify a local or remote endpoint address to which to connect a socket. An endpoint address simply contains the appropriate information to send data between two sockets on different systems. As the contents of endpoint addresses differ between network protocol families, the sockaddr structure was designed to accommodate endpoint addresses of variable size, satisfying requirements of many common network protocol families. The first field of a sockaddr contains the family number identifying the format of the remaining part of the address.

In the Internet address family, the sockaddr_in structure is used to store the endpoint address information and is cast to type sockaddr for the functions which require it. Other address families must define their own sockaddr_ structures as appropriate for their needs. For TCP/IP, the sockaddr_in structure breaks the endpoint address into its two components: port ID (sin_port) and IP address (sin_addr), and pads the remaining eight bytes of the endpoint address with a character string (sin_zero). The port and IP address values are always specified in network byte order. The value for sin_family under TCP/IP is always AF_INET (address family Internet).


struct  hostent {
        char FAR *            h_name;           
        char FAR * FAR *        h_aliases;  
        short                   h_addrtype;             
        short                   h_length;               
        char FAR * FAR *        h_addr_list;
};

The hostent structure is generally used by the Windows Sockets database routines to return host, or system, information about a specified system on the network. The host structure contains the primary name for a system including optional aliases for the primary name. Additionally, it contains a list of address(es) for the specified system. This information is generally sought for the remote system to which an application is connecting using the Windows Sockets database routines described later.


struct  protoent {
        char FAR *            p_name;           
        char FAR * FAR *        p_aliases;  
        short               p_proto;                
};

struct  servent {
        char FAR *            s_name;           
        char FAR * FAR *        s_aliases;  
        short             s_port;                 
        char FAR *            s_proto;          
};

The protoent and servent structures are also filled by the Windows Sockets database routines. These structures contain information about a particular protocol (TCP or UDP) or service (finger or telnet, for example) respectively. Along with the primary name and an array of aliases for the protocol or service, these structures also contain their corresponding 16-bit IDs, necessary to build a valid TCP/IP endpoint address.


typedef struct WSAData {
        WORD                    wVersion;
        WORD                    wHighVersion;
        char                    szDescription[WSADESCRIPTION_LEN+1];
        char                    szSystemStatus[WSASYS_STATUS_LEN+1];
        unsigned short          iMaxSockets;
        unsigned short          iMaxUdpDg;
        char FAR     *          lpVendorInfo;
} WSADATA;

Finally, the WSAData structure is filled in by a Windows Sockets DLL when an application calls the WSAStartup() API. Along with Windows Sockets version information, the structure also contains vendor-specific information, such as the maximum number of sockets available and the maximum datagram size. The szDescription and szSystemStatus members can be used by an implementation to identify itself and the current status of the DLL. For example, an implementation may return the text "Joe's ShareWare Windows Sockets implementation v1.2. 10/22/92" in szDescription. The specification of the lpVendorInfo member is completely up to an implementor and is not defined in the Windows Sockets specification.