Other Address Families

All the Winsock API functions introduced in this chapter are protocol-independent. That is, the usage presented here can easily be applied to the other protocols supported by Win32 platforms. The following sections merely describe the sample client/server code for the other protocol families found on the companion CD-ROM.

AppleTalk

A single AppleTalk sample is provided to illustrate basic client/server techniques. The sample supports both the AppleTalk PAP and ADSP protocols. The PAP protocol is a message-oriented, connectionless, unreliable protocol similar to UDP, but with two notable exceptions. First it supports partial messages, which means that a call to WSARecvEx will possibly return with only part of a datagram message. You must check for the MSG_PARTIAL flag on return to see whether additional calls are required to obtain the full message. The second exception is that you must set a socket option specific to the PAP protocol before every read. The option, SO_PRIME_READ, which is used with the setsockopt function, is discussed in Chapter 9. Take a look at the Atalk.c sample on the CD, which illustrates how to check for the MSG_PARTIAL flag and how to use the SO_PRIME_READ option.

The ADSP protocol is a connection-oriented, streaming, reliable protocol— much like TCP. The basic API calls for AppleTalk remain similar to the ones in the UDP and TCP examples presented in this chapter. The only differences will be specific to name resolution. Remember that for AppleTalk, you must bind to an empty address first before looking up or registering an AppleTalk name. This is discussed in more detail in the AppleTalk addressing section in Chapter 6.

The AppleTalk protocol has one limitation. Support for AppleTalk originated in Winsock 1.1, and when Winsock 2 was developed, it appears that AppleTalk was not fully "hooked" into the new functions. Using any of the WSASend or WSARecv functions might result in flaky results, such as negative byte count returns. This problem is actually described in the Knowledge Base article Q164565. The only exception is WSARecvEx, which is simply a recv call except that the flags parameter is in/out and can be queried for the MSG_PARTIAL flag upon return.

IrDA

The infrared protocol is a recent addition that is available on Windows CE, Windows 98, and Windows 2000. It offers only one protocol type, which is a connection-oriented, streaming, reliable protocol. Again, the only major difference in the code is the name resolution, which is significantly different from name resolution in IP. You should be aware of one other difference: because Windows CE supports only the Winsock 1.1 specification, you can use only Winsock 1.1 functions on infrared sockets on a Windows CE platform. On Windows 98 and Windows 2000, you can also use the functions specific to Winsock 2. The sample code uses only Winsock 1.1 functions. Of course, on Windows 98 and Windows 2000 you must load the Winsock 2.2 library or greater, as the support for the AF_IRDA address family is not available in earlier versions.

The sample code for infrared sockets is found in the following files: Ircommon.h, Ircommon.c, Irclient.c, and Irserver.c. The first two files simply define two common functions, one for sending data and the other for receiving data, which are used by both the client and the server. The client side is detailed in Irclient.c, which is straightforward. First all devices in range are enumerated. Then a connection attempt is made to each one with the given service name. The first device to accept the connection request is taken. Subsequently the client sends data and reads it back. On the server side of the equation is the file Irserver.c. The server simply creates an infrared socket, binds the specified service name to the socket, and waits for client connections. For each client, a thread is spawned to receive data and send it back to the client.

Note that these examples are written with Windows 98 and Windows 2000 in mind. Like the TCP/IP samples, these examples require only slight modifications to run on Windows CE. Regarding Windows CE, the two main points are that there is no support for console applications, and all functions (other than Winsock) use UNICODE strings.

NetBIOS

We've presented several Winsock NetBIOS examples. As you learned in Chapter 1, NetBIOS is capable of using several different transports, which is still the case with Winsock. In Chapter 6, you learned how to enumerate the NetBIOS-capable transports and how to create sockets based on any one of these. Each protocol-to-adapter combination has two entries: one SOCK_DGRAM and one SOCK_SEQPACKET type. These correspond to connectionless datagram and stream sockets that are quite similar to UDP and TCP sockets. Besides name resolution, the NetBIOS Winsock interface is no different from what is presented earlier in this chapter. Remember that a well-written server should listen on all available LANAs and that the client should attempt to connect on all LANAs on its end.

The first examples on the CD are Wsnbsvr.c and Wsnbclnt.c. These examples use the SOCK_SEQPACKET socket type, which for all practical purposes appears to the programmer to be stream-oriented. The server creates a socket for each LANA, which is enumerated with the WSAEnumProtocols function, and binds it to the server's well-known name. Once a client connection is made, the server creates a thread to handle the connection. From there, the thread simply reads incoming data and echoes it back to the client. Similarly, the client attempts to connect on all LANAs. After the first connect succeeds, the other sockets are closed. The client then sends data to the server and the server reads it back.

The other example is Wsnbdgs.c, which is a datagram, or SOCK_DGRAM, example. This example includes the code for both sending and receiving datagram messages. This is a connectionless protocol, so the message sent to the server is sent on all available transports (since you really don't have any idea beforehand which transport or transports will be able to reach the server). Additionally, this example supports unique, group, and broadcast data (all discussed in Chapter 1).

IPX/SPX

The IPX/SPX example, Sockspx.c, illustrates how to use the IPX protocol as well as stream and sequential packet SPXII. This single sample incorporates both the sender and the receiver for all three protocols. The particular protocol used is specified via the -p command line option. The sample is straightforward and easy to follow. The main function parses the command line arguments and then calls either the Server or the Client function. For the connection-oriented SPXII protocol, this means that the server binds the socket to the internal network address and waits for client connections while the client attempts to connect to the server that is specified on the command line. Once the connection is established, data is sent and received in the normal fashion.

For the connectionless IPX protocol, the example is even simpler. The server simply binds to the internal network and waits for incoming data by calling the recvfrom function. The client sends data to the recipient specified on the command line via the sendto function.

Two sections of the example might need a bit of explanation. First is the function FillIpxAddress, which is responsible for encoding an ASCII IPX address specified on the command line into a SOCKADDR_IPX structure. As you saw in Chapter 6, IPX represents its addresses as hexadecimal strings, which means that each hexadecimal character in the address actually occupies 4 bits within the various address fields of the SOCKADDR_IPX structure. FillIpxAddress takes the IPX address and calls another function, AtoH, which actually performs the conversion.

The second function that needs explanation is EnumerateAdapters, which is executed if the -m flag is given on the command line. This function uses the socket option IPX_MAX_ADAPTER_NUM to find out how many local IPX addresses are available and then calls the IPX_ADDRESS socket option to obtain each address. These socket options and their parameters are discussed in Chapter 9. We use these options because our example uses straight IPX addresses and does not perform any name resolution. Chapter 10 examines the name registration and name resolution that are possible for IPX.

ATM

The ATM protocol is accessible from Winsock on Windows 98 and Windows 2000. The ATM sample is contained in the files Wsockatm.c, Support.c, and Support.h. The latter two files simply contain support routines used by Wsockatm.c, such as local ATM address enumeration and ATM address encoding. ATM addresses are hexadecimal encoded, just like IPX addresses, and we use the same AtoH function. We also use the socket ioctl command SIO_GET_NUMBER_OF_ATM_DEVICES to get the number of local ATM interfaces and then use the ioctl command SIO_GET_ATM_ADDRESS to retrieve the actual address. These ioctl commands are covered in Chapter 9.

Otherwise, both the client and server sides are implemented within Wsockatm.c. Because ATM supports only connection-oriented communication, the sample isn't very long and the majority of the code is given in the main function. The server will bind to an explicit local interface and wait for client connections, which are handled in the same thread as the listening socket. This means the server will only be able to service one client at a time. We designed the sample this way on purpose, to keep the code simple. On the other hand, the client calls connect with the server's ATM address. Once the connection is established, data is sent on the connection.

A few words of caution when using the ATM protocol: you will notice that after the WSAAccept call is made within the server, the address of the client is printed out. However, at the time the server receives the connection request, the client's address is not known. This is because the connection is not fully established when the accept function is triggered. This is also true on the client side. When the client makes a call to connect to the server, it will succeed even though the connection has not been fully established. This means that upon completion of a connect or an accept call, an attempt to send data immediately might silently fail until the connection is fully established. Unfortunately, there is no way for the application to determine at what point the connection becomes valid. Additionally, ATM supports only hard closes. That is, when the application calls closesocket, the connection is immediately terminated. For protocols that do not support graceful close, any data pending on the socket at either end is normally discarded at the point closesocket is called. This is perfectly acceptable behavior; however, the ATM provider is nice to developers. When data is pending on the socket and one party has closed its socket, Winsock still returns the data queued for receiving on the socket.