This document describes how to troubleshoot a TCP/IP connection between a PC client and a UNIX or MPE/iX host.
Setting up a client-server environment can be a complex task. There are a large number of things that can go wrong before you have succesfully connected a UNIFACE client to a UNIFACE polyserver. The messages given, if at all, are not always very helpful. In these situations, it is very important that you take one step at a time, and make sure to verify that each step is working correctly before you proceed to the next one.
In this document we present a step-by-step configuration procedure, more or less assuming (after Murphy) that everything that can go wrong, will go wrong; and that everything that you assume cannot go wrong will especially go wrong. Sometimes the problem is precisely in the part you had taken for granted, and that is when it might pay off to check even the obvious things.
Please note that this document is only concerned with the non-UNIFACE part of the polyserver connection. Once you have been able to establish a connection, many things can still go wrong before your server data is safely your screen. For hints and tips in these stages we refer to existing documentation, in particular the troubleshooting sections of the UNIFACE Confituration Guide.
To be able to connect to another machine, the client PC must have either
The network card will usually be a Ethernet device, although it is also possible to use TCP/IP over a Token Ring network. If you are not physically connected to a LAN (Local Area Network), you can also use Microsoft DUN (Dial Up Networking) to create a PPP (Point To Point) connection. In this case you are not using your network card, but your modem to dial in to a corporate network which supports dial-up access. Once the connection is established, your machine can access other hosts in that network as if it were physically connected to it.
On Microsoft Windows 95/98, regardless whether you are using a LAN or DUN connection, you need to have the 'Client
for Microsoft Networks' installed. This can be done via the 'Network' applet in the Control Panel. On Windows NT,
this does not usually need to be done, as this network client is usually installed by default.
Your machine should have a valid IP address and subnet mask. These could be defined locally in the TCP/IP properties of the Network applet in the Control Panel. If this is done, you must take care that the IP address and subnet mask are compatible with the rest of the network. When in doubt, consult your network administrator.
A more common configuration is that PC's dynamically get their IP address at boot-up time from a DHCL server in the corporate network (this holds for LAN as well as DUN connections). To specify that you use a DHCP server, you must check the box 'Obtain an IP address' in the TCP/IP properties of the Network applet in the Control Panel.
Whatever your method is, after your PC has sucessfully booted up you should check whether it has an IP address and subnet mask. To do this, you run the WINIPCFG program via the Run option in the Start menu. This will show the current TCP/IP configuration. If no IP adress has been assigned, consult your network administrator before you attempt to make any connections.
We're assuming here that the UNIX or MPE/iX server you want to connect to is 'up and running', including its networking hard- and software. When in doubt, consult your network administrator. Describing how to configure a host system is beyond the scope of this document.
Your first step in setting up the connections is to check if you can reach the host at all from your PC. The command for this is called PING.EXE, which should reside in your Windows directory. You may also have a third-party PING program which you can use. To run PING, you can use the Run option in the Start menu, specifying the host name as the parameter. A better way is to manually start a MS-DOS window, run DOSKEY, and enter the "ping" command, with as argument the name or IP address of your host.
When your host is alive and kicking, PING should display something like this:
Output like this indicates that your network hard- and software is allright on both sides, and that both machines are able to communicate over the network. This seems a trivial test, but sometimes getting this far is the biggest effort in setting up a network connection.
If PING reports 100% packet loss, or 'hangs' without any mesages, this usually means that your host is not responding to any network activity. It may be down altogether, or its network software not being started. Your network/system administrator, should be able to help you here. Being able to PING your host is the first and foremost prerequisite, and before this works, there is no point in going on.
If PING reports 'Unknown host', and you are sure you did not misspell the host name, this can mean any of the following:
In this case, try using the IP address instead of the host name. If this also fails, consult your system administrator.
In case of problems, it may be worthwhile to play around with the various PING parameters. To do this, start up a MS-DOS window and enter the command
ping -?
This will show you the various command-line options you can use :
To be able to use a logical name rather than an IP address, your PC needs to have some form of name resolution. This can be achieved in two ways:
The local hosts table is a text file with the name HOSTS. This file is usually located in the C:\WINDOWS directory, but depending on the Windows TCP/IP version, it could also be located elsewhere. It may also be that this file has not yet been created. In this case you can usually find a sample file that you can copy. Typically this is the file C:\WINDOWS\HOSTS.SAM, but again, it could be located elsewhere or be called differently. If you do not yet have a hosts file, copy the file HOSTS.SAM to the file HOSTS in the same directory you found it.
A local hosts file consists of IP-address/hostname pairs, as described in the sample file. You must add the IP-adress and name of each machine you want to access by name (it is not necessary to add a host if you only use the IP address). A hosts file might look like this:
127.0.0.1 localhost 172.24.39.223 epicurus 172.24.39.119 hannibal
The address 127.0.0.1 with name 'localhost' is a so-called loopback address, which should always be included (it is already in the sample file). On any machine, 'ping localhost' is a convenient way to check your local TCP/IP configuration.
Once you have defined a name in the local hosts file, you can use that name. There is no need to re-boot the PC.
A better way of name resolution is to point the PC to a DNS server, that can do dynamic hostname lookups for the entire network. In the TCP/IP properties of the Network applet in the Control Panel, you can specify the IP adress of a DNS server. You can obtain this information from your system administrator. Using a DNS server you do not have to maintain local hosts files on every client PC, so this is a much better solution. You will need to re-start your PC after specifying a DNS server. After the reboot, check if the DNS server appears in the output of the WINIPCFG program (you start the WINIPCFG program vie the Run command in the Start menu).
Please note that name resolution is not essential to setting up a polyserver connection. It is equally well possible to use IP-addresses instead of hostnames, although we do recommend using hostnames whenever possible.
On the UNIX or MPE/iX host, polyserver connections will be initially handled by the inetd (Internet Daemon) program. The inetd is a general-purpose network listener, which uses a configuration file to determine what action to take for a specific type of request.
To be able to manipulate the inetd, you should be logged on to the server as root (in the case of MPE/iX, as MANAGER.SYS, and you must first start a shell with the command SH.HPBIN.SYS -L).
As a first check whether the inetd is up and running, enter the command
telnet localhost 7
This should start the so-called 'echo server' which simply echoes back everything you send to it. The server will wait for your input; when you enter any string, followed by Enter, it should echo back the same string. You can press CTRL-C or CTRL-D to end our conversation with the echo server.
Note that you can use the telnet program to sanity-check arbitrary services, by specifying the TCP/IP port number for that service as a parameter. If you get a message like "connection refused", this could mean either:
To see if the inetd is running at all, enter the command
ps -ef | grep inetd | grep -v grep
This should display exactly one line which will look something like
root 4192 1 0 Mar 16 ? 0:03 /usr/sbin/inetd -s
The flags for the 'ps' command and the format of the output line may vary across UNIX platforms.
An inetd service, like "polyserver", must be defined in two places before the inetd can handle it. First,
the service name and portnumber must be defined in the 'services' file. This file is called
/etc/services
on most UNIX systems and must contain a line like
polyserver 12000/tcp # UNIFACE polyserver
| | | |
| | | +--> Optional comment, starts with #
| | |
| | +--> Service protocol. Always use tcp.
| |
| +--> Service port number.
|
+--> Service name.
This will tell the inetd that there will be a service named 'polyserver' for which it must listen on port 12000. Note that you can choose this portnumber yourself. Port 12000 is just the hard-coded value that UNIFACE uses when no port is specified in the client logon path. We do recommend using values higher that 1024, because on many UNIX platforms the portnumbers below 1024 are reserved for certain privileged services.
The details of the specified service ('polyserver' in this case) must be specified in the inetd configuration file, which on most UNIX systems is called
/etc/inetd.conf
This file must contain a line like
polyserver stream tcp nowait root /usys7204/plogin plogin -d
| | | | | | | |
| | | | | | | +--> Debug flag (optional).
| | | | | | |
| | | | | | +--> Mandatory parameter.
| | | | | |
| | | | | +--> Name of your plogin executable.
| | | | |
| | | | +--> User to run as. Do not change.
| | | |
| | | +--> Wait status. Do not change.
| | |
| | +--> Service protocol. Do not change.
| |
| +--> Service type. Do not change.
|
+--> Name of service as defined in 'services' file
Depending on your UNIX variant, you may have to use additional plogin flags like -NOKA or -NOSU. Consult the readme for your platform. You can configure the inetd for multiple polyservers by using multiple port numbers and service names. For example:
/etc/services: poly7 12000/tcp poly6 13000/tcp /etc/inetd.conf: poly7 stream tcp nowait root /usys7204/plogin plogin -d poly6 stream tcp nowait root /usys61dv/plogin plogin -d
NOTE - We recommend using only spaces to separate the fields in these lines. Some inetd implementations have been seen to have problems if you use the TAB character.
Once you have updated the services and/or inetd.conf file you must re-start the inetd daemon so that it can re-read
the files. To do this, first find out the process number (PID) of the inetd process :
# ps -ef | grep inetd | grep -v grep root 4192 1 0 Mar 16 ? 0:03 /usr/sbin/inetd -s
The first number shown is the inetd's PID. Kill the process like this:
# kill -15 4192
When you are sure the process is gone (double-check with 'ps -ef'), start the inetd again:
# /usr/sbin/inetd -s
NOTE - The location of the inetd, and its arguments, may vary across platforms. The example above is from Sun Solaris
2.5. When in doubt, consult the 'man'-pages for 'services', 'inetd.conf', and 'inetd'.
NOTE - On many UNIX platforms, you do not have to re-start the inetd. Instead, you can give it a 'hangup' signal
that wil cause it to re-read its configuration files. If you know the PID of the inetd, you can use a command like
# kill -1 <pid>
or
# kill -HUP <pid>
Some UNIX platforms (not Sun Solaris) provide the '-c' flag to inetd, so you can simply enter
# /bin/inetd -c
to instruct inetd to re-read its configuration files. Consult your local inetd man page for the details for your platform.
NOTE - On MPE/iX, the inetd files reside in the MPE rather than in the POSIX domain. The files are called
INETD.NET.SYS The inetd program SERVICES.NET.SYS The services file INETDCNF.NET.SYS The inetd configuration file
Although you do not need to change this, for consistency we recommend creating symbolic links so you can use the
UNIX-style names:
# ln -s /SYS/NET/INETD /etc/inetd # ln -s /SYS/NET/SERVICES /etc/services # ln -s /SYS/NET/INETDCNF /etc/inetd.conf
(back to index)
The 'plogin' program is the link between the inetd and the polyserver. When the inetd receives a polyserver connection
request, it starts plogin which is then responsible for checking the logon parameters and firing off the polyserver.
In the previous section, you have configured the inetd for this; now it's time to check if the link actually works.
Assuming you are using the default portnumber 12000, and have restarted the inetd, you enter this command, which we commonly call the 'loopback test':
# telnet localhost 12000
This wil ask the inetd to start the plogin program, which will then be waiting for your keyboard input:
Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. _
If you see the above, and nothing else, things look good. The plogin was successfully started and is waiting for a command. It is not possible to give a sensible command from the keyboard (because of the binary data involved), so you can just type a couple of characters followed by Enter. This should typically result in the message:
Connection closed by foreign host.
This is the command-line equivalent of a 'Logon error'. If you get this far, it seems like the plogin is working allright (although yet more things might go wrong when you attempt a 'real' connection).
Two common problems can be detected by the loopback test:
1) The plogin program as specified in the inetd.conf is not found, or cannot be executed. In this case you get all the messages as decribed above, but telnet does not wait for your input. Things to check here are:
If neither of these checks help, go on to the next section, which explains how to monitor what happens at connection time.
2) The inetd is not listening for your request. This typically shows up as this response:
Trying 127.0.0.1... telnet: Unable to connect to remote host: Connection refused
This usually means that no process is listening to the port you specified. Most often this is because you did not (correctly) include the service in the inetd configuration file, or did not correctly restart the inetd. But it may also be caused by a syntax error in the configuration files, or by a problem with the inetd itself.
To find out what is happening here, you need to see what happens at the moment of connection. Read on.
Normally, the inetd will run as a background process or job, and you will not see what is happening at connection time. To be able to see what happens immediately, you need to run the inetd in the foreground, as a user process, so that its output is redirected to your terminal. As you might expect, manipulating the inetd requires root permission, so you need to be logged on as "root" (MANAGER.SYS on MPE/iX).
To run the inetd in the foreground, you first have to kill off the running inetd.
CAUTION - Once you have killed the inetd, you will not be able to telnet to your host again until you have a new
inetd process running. It is ecommended that you open an extra telnet window to your host, just in case you get
disconnected while no inetd is running.
On UNIX systems, you kill the current inetd by finding out its PID (process-id) and issuing the "kill" command against this PID. For example:
# ps -ef|grep inetd chris 1059 1020 0 12:11:14 pts/1 0:00 grep inetd root 1017 1 0 11:50:45 ? 0:00 inetd -s
In this case, the inetd's PID is 1017, so you kill the inetd with
# kill -15 1017
On HP-UX, you must kill the inetd with the command
# inetd -k
to make sure that the inetd's resources are properly freed.
On MPE/iX, you typically kill the inetd by aborting the JINETD job:
: showjob #J14 EXEC 10S LP WED 6:25P PMPELIS,MGR.PORT61DV #J19 EXEC 10S LP THU 10:04A FTPMON,FTP.SYS #J22 EXEC 10S LP THU 10:04A SAMBA,MANAGER.SYS #S185 EXEC 3 3 SUN 11:31A MGR.UTOOLS #S186 EXEC 4 4 SUN 11:32A MANAGER.SYS #J34 EXEC 10S LP SUN 12:12P JINETD,MANAGER.SYS
In this case, the JINETD job is job number 34, so you abort this job with
: abortjob #j34
NOTE - You can also run these commands from the POSIX shell, be prepending them with "callci". You must take care however of escaping or quoting any characters (like #) that would be interpreted by the shell. For example, the abortjob command as ran from the shell is:
# callci abortjob '#j34'
The command to start a foreground inetd differs slightly across systems. For all discussed systems (Solaris, HP-UX, AIX, and MPE/iX), we will list:
You can simulate an incoming polyserver connection by issuing a "telnet" command followed by the relevant
portnumber, e.g.
$ telnet localhost 12000
Platform
Inetd command
Messages on screen or in logfile
Solaris
/usr/sbin/inetd -ds
ADD : polyserver proto=tcp, wait=0, user=root, builtin=0, server=/files/applic/usys/usys72/7203/plogin
...
attempting incoming service polyserver
accept, ctrl 3
900 reaped
HP-UX
/usr/sbin/inetd -l
Mar 19 11:03:10 isophia inetd[14054]: poly7204/tcp: Added service, server /h/chris/hp8/7204/plogin
...
Mar 19 11:19:57 isophia inetd[14138]: poly7204/tcp: Connection from kitten (172.16.17.79) at Sun Mar 19 11:19:57 2000
AIX
/etc/inetd -d
Mar 31 13:08:16 serpentine inetd[17354]: ADD : polysrv proto=tcp, wait=0, user= builtin=20029398 server=
...
Mar 31 13:09:21 serpentine inetd[17354]: A connection requires polysrv service.
Mar 31 13:09:21 serpentine inetd[17354]: The accept system call returned file descriptor 5.
17570 execl /h/chris/aix/7205/plogin
MPE/iX
/SYS/NET/INETD -l
polyserver(tcp nowait MANAGER.SYS port: 12000)
polyserver/tcp: Added service, server /UTOOLS/PUB/test7204/plogin
...
Received call for: polyserver tcp
polyserver/tcp: Connection from waxmoth.nl.compuware.com (172.16.16.106) at Sun Mar 19 11:45:09 2000
NOTE - On Hp-UX and AIX, the foreground inetd does not display output directly
on the screen. Instead, it will send output to the syslog daemon syslogd, which uses its configuration file /etc/syslog.conf to determine where to write various classes of messages. On Hp-UX, inetd's messages
are written into the file /var/adm/syslog/syslog.log. To monitor what happens at runtime, you can issue this command:
# tail -f /var/adm/syslog/syslog.log
On AIX, the syslogd configuration file does not by default specify that inetd messages must be logged. You willl have to modify that file to get the messages into a file.
Running a foreground inetd can be useful to prove that you are indeed receiving an incoming connection, or if not, what the reason is. The inetd will usually report any problem it has with starting the required service program.
For example: the inetd on HP-UX reports
Mar 19 13:17:09 isophia inetd[14237]: poly7204/tcp: Connection from localhost (127.0.0.1) at Sun Mar 19 13:17:09 2000 Mar 19 13:17:09 isophia inetd[14237]: execv /h/chris/hp8/7204/plogin: Permission denied
when the specified plogin does not have its execute permission set, and
Mar 19 13:18:40 isophia inetd[14242]: poly7204/tcp: Connection from localhost (127.0.0.1) at Sun Mar 19 13:18:40 2000 Mar 19 13:18:40 isophia inetd[14242]: execv /h/chris/hp8/7204/plogin: No such file or directory
when the specified plogin does not exist.
The inetd on MPE/iX will report
polyserver/tcp: Connection from unknown (127.0.0.1) at Sun Mar 19 13:05:50 2000 execv /UTOOLS/PUB/test7204/plogin: Error: Invalid argument
when the specified plogin does not exist.
NOTE - The inetd does NOT display information about a connection attempt to a non-serviced port. In this case, the client will just receive the message
Connection refused
but no trace of this can be found in the inetd's output. As said before, 'Connection refused' simply means that there is no process listening on the specified portnumber. For the polyserver, that usually means that the inetd has not been configured correctly.
Once the inetd has been configured properly, possibly with the help of a foreground inetd, you should be able to get a "plogin" running on your server. When you have issued the command
telnet host 12000
and this command is waiting for your input, a plogin process should be running on the server. You can check that with a command like
$ ps -ef | grep -i plogin
This should give you a line that shows your plogin executable to be running. If not, you should go back to thge prevous steps to find out why the plogin has not been started.
Once you have managed to get a plogin up and running, you should also have a TCP connection between the client and host. This is not normally something you would go and check, but let's do it all the same, just so that we can discuss the "netstat" command.
The netstat command, when used without any parameters, will show you the network connections currently active on your machine. By running netstat on your PC (best done from a DOS box), you can immediately see which connections you have made. In the next example, we have establised a polyserver connection from a PC to an AIX machine, via a DUN connection. The netstat command on the PC shows:
On the third line you see a connection from the local port 1210 to the remote port 12000 (the polyserver port)
on the serpentine. The status ESTABLISHED means that the connection is currently active. The reason it mentions
the portnumber 12000 is because the polyserver service is not defined in the local services file. If this were
the case, netstat would have shown "polyserver" instead of "12000"
The netstat command on the host shows:
On the third line you see a connection to the "polyserver" service. Here, the service IS defined in the
local services file, otherwise netstat would have shown "12000" rather than "polys" (the output
is truncated a bit by netstat). Note that the foreign address is the client PC, and the remote port is 1210, corresponding
with what we saw in the netstat output on the PC. Here, too the status is ESTABLISHED, which means that the connection
is active.
With netstat, you can also see a connection that is not established yet. Suppose our host is currently switched
off, the UNIFACE application will hang while trying to connect to that machine. When you look at netstat right
then, you see this :
The machine "red", while a valid host, is not currenly switched on. The status SYN_SENT means that the
client is waiting for a response which is probably not going to come. It is a peculiarity of TCP/IP that it does
not time out on this situation. On UNIX systems, UNIFACE does handle this and forces the connection to time out
after three minutes. On other platforms, like Windows, you may have to manually abort the client.
This table lists errors you can encounter in a UNIFACE tracefile or message
frame when a connection fails. UNIFACE commonly reports these as 'Unknown error', but they are documented Winsock
errors. This is a slightly abridged version of the official Microsoft documentation. For full information we refer
to the Microsoft Developer Network (MSDN) documentation.
Code
Mnemonic
Short description
Description
10013
WSAEACCES
Permission denied.
An attempt was made to access a socket in a way forbidden by its access
permissions. An example is using a broadcast address for sendto without broadcast permission being set.
10048
WSAEADDRINUSE
Address already in use.
Only one usage of each socket address (protocol/IP address/port) is normally permitted. This error occurs if an
application attempts to bind a socket to an IP address/port that has already been used for an existing socket,
or a socket that wasn't closed properly, or one that is still in the process of closing.
10049
WSAEADDRNOTAVAIL
Cannot assign requested address.
The requested address is not valid in its context. Normally results from
an attempt to bind to an address that is not valid for the local machine. This can also result from connect, sendto,
WSAConnect, WSAJoinLeaf, or WSASendTo when the remote address or port is not valid for a remote machine (e.g. address
or port 0).
10047
WSAEAFNOSUPPORT
Address family not supported by protocol family.
An address incompatible with the requested protocol was used. All sockets
are created with an associated "address family" (i.e. AF_INET for Internet Protocols) and a generic protocol
type (i.e. SOCK_STREAM).
10037 WSAEALREADY
Operation already in progress.
An operation was attempted on a non-blocking socket that already had an operation in progress - i.e. calling connect
a second time on a non-blocking socket that is already connecting, or canceling an asynchronous request (WSAAsyncGetXbyY)
that has already been canceled or completed.
10053
WSAECONNABORTED
Software caused connection abort.
An established connection was aborted by the software in your host machine,
possibly due to a data transmission timeout or protocol error.
10061
WSAECONNREFUSED
Connection refused.
No connection could be made because the target machine actively refused
it. This usually results from trying to connect to a service that is inactive on the foreign host - i.e. one with
no server application running.
10054
WSAECONNRESET
Connection reset by peer.
A existing connection was forcibly closed by the remote host. This normally
results if the peer application on the remote host is suddenly stopped, the host is rebooted, or the remote host
used a "hard close". This error may also result if a connection was broken due to "keep-alive"
activity detecting a failure while one or more operations are in progress.
10039
WSAEDESTADDRREQ
Destination address required.
A required address was omitted from an operation on a socket. For example,
this error will be returned if sendto is called with the remote address of ADDR_ANY.
10014
WSAEFAULT
Bad address.
The system detected an invalid pointer address in attempting to use a pointer
argument of a call. This error occurs if an application passes an invalid pointer value, or if the length of the
buffer is too small.
10064
WSAEHOSTDOWN
Host is down.
A socket operation failed because the destination host was down. A socket
operation encountered a dead host. Networking activity on the local host has not been initiated. These conditions
are more likely to be indicated by the error WSAETIMEDOUT.
10065
WSAEHOSTUNREACH
No route to host.
A socket operation was attempted to an unreachable host. See WSAENETUNREACH.
10036
WSAEINPROGRESS
Operation now in progress.
A blocking operation is currently executing. Windows Sockets only allows
a single blocking operation to be outstanding per task/thread, and if any other function call is made (whether
or not it references that or any other socket) the function fails with the WSAEINPROGRESS error
10004
WSAEINTR
Interrupted function call.
A blocking operation was interrupted by a call to WSACancelBlockingCall.
10022
WSAEINVAL
Invalid argument.
Some invalid argument was supplied (for example, specifying an invalid level
to the setsockopt function). In some instances, it also refers to the current state of the socket - for instance,
calling accept on a socket that is not listening.
10056
WSAEISCONN
Socket is already connected.
A connect request was made on an already connected socket. Some implementations
also return this error if sendto is called on a connected SOCK_DGRAM socket, although other implementations treat
this as a legal occurrence.
10024
WSAEMFILE
Too many open files.
Too many open sockets. Each implementation may have a maximum number of
socket handles available, either globally, per process or per thread.
10040
WSAEMSGSIZE
Message too long.
A message sent on a datagram socket was larger than the internal message
buffer or some other network limit, or the buffer used to receive a datagram into was smaller than the datagram
itself.
10050
WSAENETDOWN
Network is down.
A socket operation encountered a dead network. This could indicate a serious
failure of the network system (i.e. the protocol stack that the WinSock DLL runs over), the network interface,
or the local network itself.
10052
WSAENETRESET
Network dropped connection on reset.
The connection has been broken due to "keep-alive" activity detecting
a failure while the operation was in progress. It can also be returned by setsockopt if an attempt is made to set
SO_KEEPALIVE on a connection that has already failed.
10051
WSAENETUNREACH
Network is unreachable.
A socket operation was attempted to an unreachable network. This usually
means the local software knows no route to reach the remote host.
10055
WSAENOBUFS
No buffer space available.
An operation on a socket could not be performed because the system lacked
sufficient buffer space or because a queue was full.
10042
WSAENOPROTOOPT
Bad protocol option.
An unknown, invalid or unsupported option or level was specified in a getsockopt
or setsockopt call.
10057
WSAENOTCONN
Socket is not connected.
A request to send or receive data was disallowed because the socket is not
connected and no address was supplied. Any other type of operation might also return this error if the connection
has been reset.
10038
WSAENOTSOCK
Socket operation on non-socket.
An operation was attempted on something that is not a socket. Either the
socket handle parameter did not reference a valid socket, or for select, a member of an fd_set was not valid.
10045
WSAEOPNOTSUPP
Operation not supported.
The attempted operation is not supported for the type of object referenced.
Usually this occurs when a socket descriptor to a socket that cannot support this operation, for example, trying
to accept a connection on a datagram socket.
10046
WSAEPFNOSUPPORT
Protocol family not supported.
The protocol family has not been configured into the system or no implementation
for it exists.
10067
WSAEPROCLIM
Too many processes.
A Windows Sockets implementation may have a limit on the number of applications
that may use it simultaneously. WSAStartup may fail with this error if the limit has been reached.
10043
WSAEPROTONOSUPPORT
Protocol not supported.
The requested protocol has not been configured into the system, or no implementation
for it exists. For example, a socket call requests a SOCK_DGRAM socket, but specifies a stream protocol.
10041
WSAEPROTOTYPE
Protocol wrong type for socket.
A protocol was specified in the socket function call that does not support
the semantics of the socket type requested. For example, the ARPA Internet UDP protocol cannot be specified with
a socket type of SOCK_STREAM.
10058
WSAESHUTDOWN
Cannot send after socket shutdown.
A request to send or receive data was disallowed because the socket had
already been shut down in that direction with a previous shutdown call. By calling shutdown a partial close of
a socket is requested, which is a signal that sending or receiving or both has been discontinued.
10044
WSAESOCKTNOSUPPORT
Socket type not supported.
The support for the specified socket type does not exist in this address
family. For example, the optional type SOCK_RAW might be selected in a socket call, and the implementation does
not support SOCK_RAW sockets at all.
10060
WSAETIMEDOUT
Connection timed out.
A connection attempt failed because the connected party did not properly
respond after a period of time, or established connection failed because connected host has failed to respond.
10109
WSATYPE_NOT_FOUND
Class type not found.
The specified class was not found.
10035
WSAEWOULDBLOCK
Resource temporarily unavailable.
This error is returned from operations on non-blocking sockets that cannot
be completed immediately, for example recv when no data is queued to be read from the socket. It is a non-fatal
error, and the operation should be retried later.
11001
WSAHOST_NOT_FOUND
Host not found.
No such host is known. The name is not an official hostname or alias, or
it cannot be found in the database(s) being queried. This error may also be returned for protocol and service queries,
and means the specified name could not be found in the relevant database.
10093
WSANOTINITIALISED
Successful WSAStartup not yet performed.
Either the application hasn't called WSAStartup or WSAStartup failed. The
application may be accessing a socket which the current active task does not own (i.e. trying to share a socket
between tasks), or WSACleanup has been called too many times.
11004
WSANO_DATA
Valid name, no data record of requested type.
The requested name is valid and was found in the database, but it does not
have the correct associated data being resolved for. The usual example for this is a hostname -> address translation
attempt which uses the DNS (Domain Name Server), and the result indicates the host itself exists, but is not directly
reachable.
11003
WSANO_RECOVERY
This is a non-recoverable error.
This indicates some sort of non-recoverable error occurred during a database
lookup. This may be because the database files (e.g. BSD-compatible HOSTS, SERVICES or PROTOCOLS files) could not
be found, or a DNS request was returned by the server with a severe error.
10091
WSASYSNOTREADY
Network subsystem is unavailable.
This error is returned by WSAStartup if the Windows Sockets implementation
cannot function at this time because the underlying system it uses to provide network services is currently unavailable.
11002
WSATRY_AGAIN
Non-authoritative host not found.
This is usually a temporary error during hostname resolution and means that
the local server did not receive a response from an authoritative server. A retry at some time later may be successful.
10092
WSAVERNOTSUPPORTED
WINSOCK.DLL version out of range.
The current Windows Sockets implementation does not support the Windows
Sockets specification version requested by the application. Check that no old Windows Sockets DLL files are being
accessed.
10094
WSAEDISCON
Graceful shutdown in progress.
Returned by WSARecv and WSARecvFrom to indicate the remote party has initiated
a graceful shutdown sequence.