lynx-dev Explaining Error 115 in `SOCKET_ERRNO' (was: lynx+openssl)

[Klaus Weide]

On Tue, 25 Jan 2000, Eldon Mellaney wrote:

> New to the Lynx mailing list, but I thought I could add something ...

Nice explanation; corrections only to some details:

> When a system call is made, e.g., connect(...), the operation may be carried
> out in one of two ways.
> 
> When an application requests something from the operating system (which is
> the resource manager) using a system call, e.g., establish a TCP connection
> using connect(), control is passed to the operation system so that it can
> handle the request.
> 
> A system call, e.g., connect(), is said to be blocking if the application
> which has made the request of the operating system will wait indefinitely
> for an answer from the operating system. In such cases, the application is
> said to be "blocked" while it waits for a response (either positive or
> negative) from the operating system.
> 
> If on the other hand, the application programmer has explicitly told the
> operating system that the application is unwilling, or unable, to wait
> indefinitely for an answer, but still wishes the operating system to attempt
> to carry out the request, e.g., establish a TCP connection, then the system
> call is said to be "non-blocking". In such cases, control is passed to the
> operating system long enough for it to determine if it can carry out the
> request _immediately_. If it cannot, the operating system immediately passes
> control back to the application.
> 
> In the "non-blocking" case, the application programmer must handle the case
> when a request for a resource cannot be completed immediately and control is
> passed back to the application. One obvious, but very flawed, approach that
> the programmer may take is to have the application attempt indefinitely to
> acquire the resource it wants. This is called "busy waiting" and is very
> wasteful of precious system resources, e.g., CPU cycles are spent changing
> control from the operating system to the application program and back again
> (called "context switching").
> 
> In the case below, the connect() system was non-blocking. 

Yes.

> The operating
> system attempted to establish the TCP connection, but could not do so when
> the request was made.

This is actually the normal case when making a non-blocking TCP connect().
It would be unusual to get an immediate success.  (Maybe it could happen
sometimes when connectiong to "localhost".)

> Control was first passed to the operating system so
> that it could determine whether the request could be carried out. Next, once
> the operating system determined it could not carry out the request, it
> immediately responding by returing a value to the application that made the
> connect() system call. The value returned, i.e., return value of connect(),
> indicates that the request to establish a TCP connection was not successful.

The value returned is -1.  The application then has to look at the errno
variable to find out more - esp. whether a "real" error occured or just
the normal non-blocking behavior (which appears like an error).

> As a result, the program must now decide how to proceed: attempt again, but
> attempt no more than N times (and hopefully with some delay between
> attempts! Perhaps an exponential back-off algorithm that produces longer
> delays with each failure.) or to quit trying because the host you are trying
> to reach at the specified TCP port is unavailable. (Examine the return value
> of connect() to see the reason for failure.)

Lynx doesn't do exponential back-off (it just calls select() repeatedly,
with a timeout and intermediate checking for keyboard input).  But
hopefully the OS's network stack does exponential back-off for resending
the initial packet.  

> In the specific example below,
> it appears that the first call to connect() failed (and the return value was
> set to 115 to indicate the cause), but that a subsequent call to connect()
> (would appear to be the second attempt) succeeded as the message "Operation
> now in progress" was written to standard output.

> TCP: Error 115 in `SOCKET_ERRNO' after call to this socket's first connect() 
> failed.
>       Operation now in progress

Actually these are two lines of info from the same connect() call:

The first line says where it happened and gives errno as a number (115).
The second line is just a text message explaining what errno==115 means.

   Klaus