TCP/IP Programming Manual

• Because of differences between the UNIX and NonStop operating system I/O environments,
some differences exist in the errors returned in errno by the socket routines. Although errors
that have the same names are compatible, some error numbers do not match those returned
by UNIX implementations. Programs that refer to errors by number rather than by name require
a greater conversion effort.
In particular, those socket errors that represent UNIX operating-system-dependent errors are
not returned, and NonStop operating system file-system errors can be returned. For details,
see Appendix B.
• Sockets can be closed or removed only by calling the file-system procedures FILE_CLOSE
or CLOSE.
• File control provided by the UNIX fcntl system call is not supported.
• The functions recv[from]_nw and t_recvfrom_nw require the use of the AWAITIOX
procedure to determine the number of characters read.
• The function send[to]_nw requires the use of the AWAITIOX procedure to determine the
number of characters sent. If the amount of data sent is less than the length of the message,
issue another pair of send_nw and AWAITIOX calls.
To determine the number of characters sent through a call to send_nw or t_sendto_nw,
you can alternatively look at nb_sent, which is the first parameter of struct send_nw_str.
See the description of the send_nw routine in Chapter 4 for information about this structure.
• The NonStop server implementation of database-support routines such as gethostbyaddr,
gethostbyname, getnameinfo, and getaddrinfo, are all waited calls.
• NonStop TCP/IP, Parallel Library TCP/IP, and NonStop TCP/IPv6 sockets provide the
sockaddr data structure for IP address, address family, and port information as a pointer to
the HP-defined sockaddr_in data structure. Functionality for both data structures is identical.
• In the NonStop TCP/IP, Parallel Library TCP/IP, and NonStop TCP/IPv6 implementations,
Read and Write operations are not supported for Guardian sockets.
Asynchrony and Nowaited Operations
Asychrony mechanisms differ depending on whether you are dealing with OSS sockets or Guardian
sockets (for OSS, see the Open System Services Programmer’s Guide). Asynchrony refers to the
issuance and completion of an operation occurring at different times. Synchronous operations
happen stepwise when your program runs; that is, the completion occurs as a result of returning
from the function.
In Guardian, specific versions of the library routines (functions) end in _nw; for example, send_nw
and recv_nw. nw stands for nowait. (See Nowait I/O (page 32) for more information.)
A function is initiated upon return of the function call but the function is not necessarily completed.
At some point, for a Guardian program, the application runs out of things to do and is ready to
wait for notification about completion of all the different asynchronous functions that the application
has initiated. This behavior is typical of servers. Servers cannot afford to wait for operations to
complete because waiting means they are not serving someone else. Eventually, the server calls
AWAITIOX which is a Guardian function that allows the application to rendezvous and either wait
or get any completions that are pending. If no functions are finished, AWAITIOX waits as long as
you specified in a parameter that you sent to AWAITIOX. This wait time can be anywhere from 0
to infinity. Eventually, when the completion occurs, AWAITIOX returns and tells the application
why it woke up (AWAITIOX can wait for multiple reasons.)
When the application gets a return from AWAITIOX, the parameter returned is a file number which
corresponds to the socket. A tag is also returned. One parameter to recv_nw, send_nw, is a
tag, because if the application is doing multiple operations at once, it must be able to differentiate
between the operations. So a unique value is associated with each operation (for example, multiple
34 Introduction to Programming to the Guardian Sockets Library