TCP/IP Programming Manual

requester-server model—that is, a client is the same as a requester. Programming Using the Guardian
Sockets Interface (page 32), explains how to develop client and server programs that use sockets.
Stream-Oriented Protocol Considerations
Unlike a protocol that sends and receives blocks or buffers of packets at a time, TCP is a
stream-oriented protocol. The data has no boundaries except those put there by applications using
TCP/IP. For example, the fact that the application sent 1,000 bytes does not mean the receiving
end receives 1,000 bytes. The receiving end may only receive one byte; the network may only
deliver in small chunks. The act of sending simply buffers the data for transfer, it does not imply
that data has been sent or received. Completion of a receive simply provides the data that has
been correctly received up to that point, up to the amount requested by the receive. When the
application issues a receive function, all it specifies is how much data it can receive, that is, how
big the buffer is. The application may get less data than it can receive.
If your application must be able to examine a whole record or block of data, it must embed data
that marks or describes the blocks in the data. On the receiving end, the application receives the
stream and looks for the block or record marks or has a previous definition of the record size. That
is, if the application had a fixed record size of 80 bytes, the application would have to fragment
the data itself. For example, if your application posted a receive for 1,000 bytes and received
800 (10 records X 80 bytes) the application would not need to fragment the data. But if the
application posted a receive for 1,000 bytes and received 850 bytes, the application would have
10 whole records and one partial record and would need to keep track of the partial record,
posting more receives to get the remaining data. The application also needs to know when it is
finished, either through loss of connection, a pattern of bytes in the stream, a particular record
type, or from some other event.
Passive Connect Compared to Active Connect
Passive connect means that the application sits listening for incoming connections, that is, passive
connect posts an accept call. (In the OSS socket programming model, you would post a listen
call.)
A server would most likely use the passive connect model.
The active connect model means the application initiates a connect by calling connect (or
connect_nw). This call makes a connection to somebody listening for connections. Servers typically
listen for connections.
Domain Name Resolution
When your program requests information about a host, the Domain Name resolver provides
name-address resolution services. The Domain Name resolver is a programmatic interface consisting
of socket-library support routines that get information about hosts, networks, protocols, and services.
See Table 12 (page 82) for a list of these routines.
Depending on which support routine your program calls and the value defined for
=TCPIP^HOST^FILE at the time the program runs, the Domain Name resolver accesses either a
name server or one or both of two special host files that contain a list of Internet addresses and
each of the corresponding hostname and alias(es) for those addresses. The default names of these
files are $SYSTEM.ZTCPIP.HOSTS and $SYSTEM.ZTCPIP.IPNODES. (IPNODES is available
for NonStop TCP/IPv6 or CIP.) If the address information is contained in some other file, each user
running the program must define a value for =TCPIP^HOST^FILE and, for NonStop TCP/IPv6
or CIP, =TCPIP^NODE^FILE. Add DEFINE for =TCPIP^NODE^FILE, only when you want to
place the IPNODES file in a location other than the default $SYSTEM.ZTCPIP.
The socket library uses the DEFINE command to resolve file names or process names. The DEFINE
command is described in the TACL Reference Manual. Information about using the DEFINE command
is in the HP NonStop Kernel Operating System Users Guide.
26 Introduction to Programming to the Guardian Sockets Library