Berkeley CSUA MOTD:Entry 10750
Berkeley CSUA MOTD
 
WIKI | FAQ | Tech FAQ
http://csua.com/feed/
2025/07/08 [General] UID:1000 Activity:popular
7/8     

2003/10/23 [Computer/SW/Database] UID:10750 Activity:very high
10/22   Sockets again (WinSock): select() on my socket descriptor fails with
        error 10038 (http://www.sockets.com/err_lst1.htm#WSAENOTSOCK which
        means the socket is not valid.  But I just created the f**ing thing.
        Any ideas?  This happens on both server & client.
        Update: I can select() without errors until I try to send(), then it
        fails.
        \_ Server or client?
           \_ Ok, this is screwier than I thought.  Thanks for your help,
              but I'm going to sleep on it-- when I simplified it a bit,
              select() started returning data ready, but recv() kept
              returning 0 bytes.  Again, thanks.
Cache (8192 bytes)
www.sockets.com/err_lst1.htm#WSAENOTSOCK -> www.sockets.com/err_lst1.htm
The Windows Sockets API does not have analogs for the Berkeley perror and herror functions that take the error value as input, and output the short text of each error value we show the code for an alternative in Chapter 10, Support Routines. Since Windows Sockets is practically a clone of Berkeley Sockets, and the rule of thumb is when in doubt, defer to Berkeley , we can adopt the Berkeley Software Distribution error text as our own. We took the text of the errno manual page in BSD 43, filled in gaps and embellished, completing the information. The Windows Sockets errors are listed in alphabetical order below theyre cross-referenced in a list in numerical order further below. Every error description contains at least: Summary Info : Error macro: manifest constant, as defined in WINSOCKH Error value: as defined in v11 WINSOCKH Short description Berkeley description : text describing the equivalent BSD 43 error value with some input from other Unix errno values as well. Most of the text comes from the output from the man errno command on Unix. WinSock description: a quick comparison to the Berkeley counterpart, and a long description of WinSock error. WinSock functions: the list of functions that explicitly list this error in the v11 Windows Sockets specification. Some of the types of things you will find under some errors are: Microsoft C description : the first few WinSock errors are carry-overs from the standard C runtime library. Detailed descriptions : the specific meanings that some WinSock functions have for some errors. TCP/IP scenario: description of the TCP/IP protocol suite network traffic ie TCP, UDP, ICMP, ARP, DNS that typically causes the error. Developer suggestions : Things an application developer can do to avoid the error. User suggestions : Things an application user can do to diagnose the error condition further, and/or remedy it. Additional functions: a generic description of the type of functions that can return this error, which may include functions other than those listed by the WinSock specification. It may also make explicit mention of other functions that can fail with this error. Developers should consider handling the referenced errors similarly. Although most of this appendix is for application developers, the User suggestions contain information that end-users and application support personnel might also find useful when an application fails. We suggest local configuration changes that might remedy the problem, and network and server conditions that might be the cause. The errors that have User suggestions are all the same ones in the User-fixable errors list above. The WinSock description and TCP/IP scenario contain detailed descriptions of the errors, which also describe possible cause and imply a possible remedy. For more information on debugging problems, see Chapter 13, Debugging. Errorless Functions Eight of the forty-six functions in the Windows Sockets API are not referenced in any of the WinSock function lists in the following detailed descriptions. The v11 WinSock specification doesnt list any errors for these functions. Specifically, these error-less functions are the byte order functions htonl , htons , ntohl , and ntohs , the address manipulation functions inet_addr , and inet_ntoa , WSAGetLastError and WSAIsBlocking . Some of these functions cannot fail, which explains their absence from the error list below. Of the two that can fail, neither of them set an error value you can retrieve from WSAGetLastError refer to Chapter 10, Support Routines for more information on any of these error-less functions. As we pointed out earlier, your application should be ready to encounter any error at any time. Although the specification doesnt list an error for a function, it does allow for it. In fact, on occasion you can benefit if the WinSock implementation returns these other errors. This can help you or your support staff to zero-in on whats wrong when your application runs into a problem. Some WinSock implementation use these errors inappropriately, but they have a particular meaning. They signal unusual error conditions for which theres no WinSock error equivalent. Unfortunately, to find out what these errors mean you need to contact that WinSock provider. Error Description List <no macro available> 0 No error WSABASEERR 10000 No error Berkeley Description: no equivalent. Detailed description: Theres at least one WinSock implementation that will occasionally fail a function and report this as the error value, even though the function succeeded. Berkeley description : An attempt was made to access a file in a way forbidden by its file access permissions. This error signifies that an attempt was made to access a file or, in some cases, a directory in a way that is incompatible with the files attributes. For example, the error can occur when an attempt is made to read from a file that is not open, to open an existing read-only file for writing, or to open a directory instead of a file. Under MS-DOS versions 30 and later, EACCES may also indicate a locking or sharing violation. The error can also occur in an attempt to rename a file or directory or to remove an existing directory. Detailed description : send & sendto : the requested address is a broadcast address, but the appropriate flag was not set ie you didnt call setsockoptSO_BROADCAST. WinSock functions : send , sendto Additional functions : setsockopt and any function that takes a socket or file handle as an input parameter. Berkeley description : Only one usage of each address is normally permitted. The address they refer to, typically refers to the local socket name, which is made up of the 3-tuple: protocol, port-number and IP address. Instead, let the network system assign the local port very few application protocols require a client to bind to a specific port number or port number range. Alternately, you could call setsockoptSO_REUSEADDR to allow duplicate local addresses in a single application, but this is a kludgy approach ie we dont recommend it. User suggestions: Dont try running two of the same types of server applications on the same machine. For instance, this error will occur if you try to run two applications that have FTP servers. Winsock functions: bind , connect , listen , FD_CONNECT WSAEADDRNOTAVAIL 10049 Cannot assign requested address . Berkeley description : Normally results from an attempt to create a socket with an address not on this machine. The address it refers to is the remote socket name protocol, port and address. This error occurs when the sin_port value is zero in a sockaddr_in structure for connect or sendto . In Berkeley, this error also occurs when you are trying to name the local socket assign local address and port number with bind , but Windows Sockets doesnt ascribe this error to bind , for some unknown reason. Let the network system assign the default local IP address by referencing INADDR_ANY in the sin_addr field of a sockaddr_in structure input to bind . Alternately, you can get the local IP address by calling gethostname followed by gethostbyname . WinSock functions : connect , sendto , FD_CONNECT Additional functions : It seems odd that the v11 specification doesnt ascribe this error to the function bind . WSAEAFNOSUPPORT 10047 Address family not supported by protocol family . Berkeley description : An address incompatible with the requested protocol was used. For example, you shouldnt necessarily expect to be able to use NS addresses with ARPA Internet protocols. The error occurs with the socket function, which takes the socket type protocol and address family as input parameters. It also occurs with functions that take a socket handle and a sockaddr structure as input parameters. A socket already has a type a protocol, and each sockaddr structure has an address family field to define its format. A function fails with WSAEAFNOSUPPORT if the address family referenced in sockaddr is not compatible with the referenced sockets protocol. This error apparently also takes the place of WSAEPFNOSUPPORT which means protocol family not supported, since that error is not listed for socket in the v11 WinSock ...