 | |
|
CHAPTER 3
Networking and STREAMS
Networking: Sockets, XTI, TPI, DLPI- Code Changes- Sockets - XTI - TPI - DLPI The Solaris 2.6 operating environment provided UNIX95 interfaces that were based on XPG4.2, which includes XNS4.2 (X/Open Networking Services v4.2). The UNIX98 standard is based on XNS5. The most significant changes in XNS5 and the other concurrent networking standards are the 64-bit fixes described in the following sections. The 64-bit Solaris networking facilities are closely aligned to XNS5.
Code ChangesWhen programming to any of the interfaces described in the following sections, change the types of all variables or structure members that relate to arguments of functions or fields in any structures. In most cases, the C type promotion rules deal with any integral type incompatibilities, as long as the type involved is large enough to hold the necessary values. Be especially careful to fix any uses of pointers to address specific fields in any data structure. Failure to repair these can lead to actual program errors under LP64 (where a long is not the same size as a t_scalar_t).
Caution - Do not ignore compilation warnings during conversion for LP64. Even those that could be safely ignored in the ILP32 environment might now indicate a more serious problem.
SocketsOriginally, most integers in the socket interface were of type int. In XPG4.2, all of those that described the size of memory objects were changed to size_t or ssize_t. Because these are difficult types to deal with on a system that supports both ILP32 and LP64 data models, only those structure fields and function types that really need to describe arbitrary amounts of data should use them. The other places where those fields and types have been used to describe inherently small data items (for example, network address lengths) can remain 32-bit types.Because several vendors have already shipped implementations based on size_t, a new data type socklen_t was created. It is an unsigned opaque integral type of at least 32 bits in size. So, socklen_t is used for the address_len in accept(3N), bind(3N), connect(3N), getpeername(3N), getsockname(3N), recvfrom(3N), and sendto(3N). The new type is also used for the option_len argument in getsockopt(3N) and setsockopt(3N). Instruct msghdr from <sys/socket.h>, socklen_t is the type of msg_namelen and msg_controllen, and in struct cmsghdr it is the type of cmsg_len. Under UNIX95, the XNS4.2 definitions were only available under a specific compilation environment through feature-test macros specifically requesting them. The standard environment provided the older Berkeley-style prototypes. Currently, the kernel and default types are the XNS5 versions discussed here.
Programming NotesChange any variables or structure fields relating to socket arguments or fields so they are the same type as that argument or field. Note particularly those variables or fields that are now of type socklen_t, size_t, or ssize_t.
XTIThe changes made to the X/Open Transport Interface (XTI) are in the same general vein as those mentioned for sockets. Most of these APIs originally used the type long to ensure that 32 bits were used.The header <xti.h> now defines t_scalar_t and t_uscalar_t respectively as a signed and unsigned opaque integral type of equal length of at least 32 bits. Every previous use of long in XTI is now t_scalar_t and every use of unsigned long is t_uscalar_t.
Programming NotesChange any variables or structure fields relating to XTI arguments or fields to the same type as that argument or field. Note particularly those variables or fields that are now of type t_scalar_t, t_uscalar_t, or size_t.
TPIThe Transport Provider Interface (TPI) is a message-based interface between Transport Users and Transport Providers. A Transport User can be an API like Sockets or XTI, or a program or kernel component that talks to TPI directly. A Transport Provider is (usually) a special type of device driver, often a multiplexer that carries out conversations with a number of Transport Users at the other end of STREAMS.Because it is extremely difficult to identify the original data model (ILP32 or LP64) of general STREAMS messages, the generalized message protocols like TPI and DLPI were changed to contain elements that would be the same size, independent of the data model. The original use of long in TPI and DLPI made it necessary to change their definitions. Every previous use of long in XTI is now t_scalar_t and every use of unsigned long is now t_uscalar_t. This change has been incorporated into The Open Group's Transport Provider CAE Specification v1.0.
T_CONN_RES and I_FDINSERTOne of the data items making up the TPI specification was a field called QUEUE_ptr, which was defined to be a pointer to a kernel queue structure. This field has been redefined as a t_uscalar_t called ACCEPTOR_id. This redefinition preserves binary compatibility under ILP32, but any program, user, or kernel, that makes explicit reference to it will fail to compile.A reference to this field seldom needs to be made in any application. The contents were traditionally a pointer to a kernel data structure and were filled in with a special STREAMS ioctl I_FDINSERT. The XTI specification does not specify this field or its semantics. I_FDINSERT walked down the STREAMS data structures of a STREAMS queue until it found the end, inserted the read side queue pointer of that endpoint in the message, then sent it down a second STREAM. This behavior is preserved on the 32-bit Solaris kernel. On the 64-bit Solaris kernel, other mechanisms are employed.
Note - Since this area of the revised Solaris kernel interface has not been completely decided, no details can be given now. All that is currently guaranteed is that users of either the XTI or Sockets interfaces over TCP/UDP/IP will obtain correct results. For the most up-to-date information, see the STREAMS Programming Guide.
Programming NotesChange any variables or structure fields relating to TPI message fields to the same type as that field, that is, either t_scalar_t or t_uscalar_t.
DLPIThe Data Link Provider Interface (DLPI) is the interface between Data Link Users (normally Transport Providers) and Data Link Providers (normally hardware device drivers) and has the same problems as TPI. Therefore, every previous use of long is now t_scalar_t, and every use of unsigned long is t_uscalar_t. In addition, two fields that were typed ushort have been changed to uint16_t.
Programming NotesChange any variables or structure fields relating to DLPI message fields to the same type as that field, that is, either t_scalar_t, t_uscalar_t, or uint16_t.
| ||||||||||
| |
| ||||||||||||
Print-friendly Version
