_~a.t ~e c h n o lo~, 3 .,~ o TIME-SHARED COMPUTING wo decades ago, the data processing industry was using powerful mainframes with the users sharing CPU cycles and data storage facilities. Access to the mainframes was tightly controlled by MIS departments and the only method of accessing the data from mainframes was through punched cards or primitive terminals. We saw evolution of pioneering data retrieval and analysis methodologies in the years to come; yet the techniques were arduous and constrained due to centralized resources and user- hostile interfaces. Thus, when PCs came to the computing industry in the early 1980s, their growth was phenomenal, as they provided limited CPU cycles and data storage facilities on user desktops, user control over desktops, and user-friendly PC-based software. Aiok Sinha COMMUNICATION$OFTHIE ACM/Ju|y 1992/Vo135, No.7 77
`
`Netflix v. GoTV
`IPR2023-00757
`Netflix Ex. 1016
`
`

`

`PCs, however, were still incapa- ble of handling data processing needs of most large businesses. Local area networks (LANs) pro- vided the solution by connecting PCs and mainframes. Thus, the PC where present, was used as a user- friendly "terminal" to the host. At the same time, we saw the evolution of LAN and PC-based file and print Servers (e.g., Novell Netware started in 1983 and Microsoft MS- Net-based LAN software, such as IBM PC-LAN started in the 1984- 85 year). In 1989, in a survey by Infonetics of Santa Clara, 20% of PC LAN buyers cited the desire to share printers, while 22% cited the sharing of large mass storage de- vices as buying motivation 6. As we will discuss in the next section, file and printer sharing does not lead to Client-Server applications. Today, both PCs and LANs have a large installed base in corpora- tionsl; so have PC-based word- processors, spreadsheets, and data- base programs. Thus, while the PC- based software has allowed a variety of processing to be done on the desktop, PC LANs have allowed sharing of files and peripherals to take place at the department level in corporations. We have also seen Unix worksta- tions getting larger installed bases in corporations. These are typically used for "specialized applications." Worldwide Unix workstation reve- nue from "the commercial market" is expected to rise from $0.8 billion in 1990 to $4.6 billion in 1994, while the revenue from "the techni- cal market" is expected to grow from $6.6 billion in 1990 to $10.7 billion in 1994 20. Most of the "Mission critical ap- plications" in corporations, how- ever, have remained mainframe- (and minicomputer-) centrio "Mis- sion critical applications" can be *PC-installed bases in U.S. government, busi- nesses, and education were estimated to be 33.4 million units in 1990 and are expected to grow to 69 million units by 1994. 34.2% of PC-installed bases in 1990 are connected through LANs; 65.2% of PC-installed bases are expected to be connected by LANs in 1994. DataQuest (Mar. 1991). loosely defined to be those infor- mation processing and analysis applications whose output is used by corporations for strategic deci- sions. Almost universally, finance management systems are consid- ered "mission critical applications." The "criticality" of one set of appli- cations over another is often deter- mined by the business of the corpo- ration (e.g., transaction processing systems are often the most "critical" applications for the airline compa- nies). Indeed, today the Network in- dustry in general and the LAN and Database Server Industry in partic- ular is very excited about "downsiz- ing" mainframe applications to PC Servers and LANs using the Client- Server Computing paradigm. Their enthusiasm is causing MIS shops to take more serious notice of this new paradigm. Of course, this has resulted in the development of new network operating systems and database architectures to sup- port the Client-Server Computing model. 2 Client-Server Computing Paradigm Definitions In the Client-Server computing paradigm, one or more Clients and one or more Servers, along with the underlying operating system and interprocess communication sys- tems, form a composite system al- lowing distributed computation, analysis, and presentation. We will call such a composite system a "Client-Server System" or simply CSS. In such a system, a Client is a process which interacts with the user and has the following charac- teristics: A It presents the User Interface (UI). This interface is the sole means of garnering user queries or 2Network operating systems (NOS) provide network functionalities besides normal (local) file-system functionalities. These typically have network-aware modules embedded within the operating system kernel. Microsoft Lan Manager Server or 4.3 BSD Unix is a very good example of a NOS. directions for purposes of data re- trieval and analysis, as well as the means of presenting the results of one or more queries or commands. Typically, the Client presents a Graphical User Interface (GUI) to the user (e.g., Microsoft Windows- based interfaces). As a CSS can consist of multiple Clients, multiple User Interfaces may exist in a CSS, but each Client will have a single consistent UI, e.g., a CSS may have both Micro- soft Windows or Presentation Man- ager (PM) Clients. A CSS may have interfaces in addition to the User Interface for administrative control and system management. B It forms one or more queries or commands in a predefined lan- guage for presentation to the Server. The Client and the Server may use a standard-based language such as SQL or a proprietary lan- guage known within the CSS. Each user query or command need not necessarily map a query to the Server from the Client. A Client may use caching and optimization techniques to reduce queries to the Server or perform security and access control checks. A Client may also check integrity of queries or commands requested by the user. Sometimes it may not be necessary to send a query to the Server at all. In such cases, Client may itself perform the data pro- cessing requested by the user and satisfy the user query or command. It is however, recommended that Client applications do not provide these functionalities and we ask that they foist these on the Server appli- cation. For example, if the Server manages security, it is much more difficuh for intruders to break in. C It communicates to the Server via a given Interprocess communication methodology and transmits the queries or commands to the Server. An ideal Client com- pletely hides the underlying com- munication methodology from the user. D It performs data analysis on the query or command results sent from the Server and subsequently 78 July 1992/Vol.35, No.7/COMMUNICATIONS OF THE ACM
`
`

`

`presents them to the user. The na- ture and extent of processing on the Client may vary from one CSS to another. The Client characteristics B and D set it apart from dumb termi- nals connected to a Host, since it possesses intelligence and process- ing capability. 3 On the other hand, Client characteristic D must not be confused with a PC connected to a LAN, which downloads all the nec- essary files from a Server or a Host and does all the processing locally. In a CSS, a Server is a process, or a set of processes all of which must exist on one machine which pro- vides a service to one or more Cli- ents. It has the following character- istics: A. A Server provides a service to the Client. The nature and extent of the service is defined by the busi- ness goal of the CSS itself. Thus, an accounting CSS Server provides an accounting data retrieval and pro- cessing service to the Client. A service provided by a Server may require minimal Server-based computation (e.g., print servers or file Servers) to intensive computa- tions (e.g., database servers or Image-Processing servers). B. A Server merely responds to the queries or commands from the Clients. Thus, a Server does not ini- tiate a conversation with any Client. It merely acts either as a repository of data (e.g., file Server) or knowl- edge (e.g., database Server) or as a service provider (e.g., print Server). C. An ideal Server hides the entire composite Client-Server sys- tem from the Client and the user. A Client communicating with a Server should be completely unaware of the Server plaform (hardware and software), as well as the communi- cation technology (hardware and software). For example, a DOS- based Client should be able to com- municate with a Unix or OS/2- based Server in the same manner, regardless of the operating system 3See section on X-Windows for differentia- tion between CSS and X-Windows Client/ Server. on the Server(s) and LAN technol- ogy connecting the Client to the Server(s). It is advisable, and desirable, that in a multiserver environment, the Servers communicate with one an- other to provide a service to the Cli- ent without its knowledge of the existence of multiple Servers or intra-server communication. Thus, in such a distributed processing environment, the Client should be unaware of the locale of one or more Servers servicing the Client query or command. Thus, a Client/Server architec- ture divides an application into sep- arate processes operating on sepa- rate machines connected over a network, thus forming a "loosely coupled" system. 4 An application designer divides the user-defined task into subtasks to be completed either by the Client or by the Serv- er(s) within the constraints posed by business goal of the CSS itself and funtionalities provided by the un- derlying network operating system. The more advanced the network operating system, the smaller (code-wise) the application will be. For example, Microsoft LAN Man- ager provides a rich set of functionalities geared toward de- veloping CSS. Thus, a CSS running on top of LAN Manager will itself contain less code--which leads to reduced development time. If, however, the same CSS were to run on top on a network operating sys- tem which merely provides file/ printer sharing, CSS code can easily double. Industry Perspective At present, most corporate applica- tions are either mainframe-centric or PC-server-centric. In main- frame-centric environments, users interact with applications running on mainframes through terminals or PC-based terminal-emulators which have the following character- istics: 4Ideally, the Client and the Server may exist on the same machine without any network involvement; nevertheless, almost all Client- Server Systems of interest have a network subsystem. • They may present a proprietary User Interface. Typical terminals or terminal-emulators present a non-GUI interface (e.g., IBM 3270 terminals or emulators). In recent years, the terminal-emulator indus- try has attempted to present graph- ical interfaces while hiding non- graphical and proprietary interfaces from the users. • Typically, all user key strokes and cursor positions are transmitted to the mainframe. Thus, no local in- telligence or processing is required, except that required for the trans- mission of the user commands or queries. • Simple terminals are typically hardwired to the mainframe or to a local terminal controller, which in turn is connected to mainframes via cluster controllers, while PC-based terminal emulators are either re- motely connected to the main- frames through modems or con- nected to the mainframe through a LAN (Figure 1) • Typically, all results returned from the mainframes are in terms of cursor positions and characters or strings to be displayed at certain positions on the screen. All compu- tations as well as UI control and rendering is done by the main- frame. This causes excessive load- ing on expensive mainframe re- sources, such as storage systems and CPU cycles, and is the main disadvantage of mainframe-centric systems. • Mainframe-centric systems ac- cord tight administrative control as well as comprehensive system man- agement and performance man- agement facilities. In PC-Server-centric environ- ments, on the other hand, PCs share applications, and data reside on one or more PC-based Servers. This environment provides flexibil- ity to the individual user, but ad- ministrative control and system management tools are minimal. These systems have the following characteristics: • Typically, the PC-based Server is used to share printers and share common applications and data COMMUNICATIONS OF THE AOM/July 1992/Vol.35, No.7 79
`
`

`

`Time- Shared Computer I I I Front End Processor Terminal Controller I I I Terminal Controller C, LAN Remote Server I t X.25 Communcation Server ® ® Figure 1. Terminals connected to a time-shared computer Figure 2. PCS connected to PC-Serv- ers over LAN (files only). The file Servers provide a range of services to share data among one or more PC applications (Figure 2). • Each application presents UI and has complete control of the inter- face as well as rendering of the re- sults. Recent years have seen an explosive growth of GUI-based applications. • Usually, all user commands or queries are processed on the PC it- self. Thus, there must be a large RAM in the PC to enable it to run sophisticated (and thus large) appli- cations. This works against corpo- rate desire to provide cost-effective desktops to the users. Furthermore, the PC-based application may inter- act with the file Server for accessing (shared or private) data. This causes high volume network traffic since data file(s) must be transported from the file Server onto the PC's local memory. This is particularly true for PC-network- based database programs. To- gether, these two drawbacks of PC- based applications form the main disadvantage of PC-server-centric systems. A CSS provides an ideal solution to the drawbacks of both main- frame-centric and PC-Server- centric systems. The most impor- tant features of a CSS are • Desktop intelligence, since the Client is responsible for UI. It transforms the user queries or com- mands to a predefined language understood by the Server and pre- sents the results returned from the Server to the user. • Sharing the Server resources (e.g., CPU cycles, data storage) most optimally. A Client may re- quest the Server to do intensive computation (e.g., image process- ing) or run large applications on the Server (e.g., database servers) and simply return the results to the Client. • Optimal network utilization as the Clients communicate with the Server through a predefined lan- guage (e.g., SQL) and the Server simply returns the results of the command as opposed to returning all the data files. • Providing an abstraction layer on the underlying operating systems and communication systems such as LAN, allowing easy maintenance and portability of the applications for years to come. Comparisions with Time-Shared Systems. It is widely acknowledged in the computer industry that CSS systems are being widely consid- ered by corporations for new appli- cations. Often, MIS professionals are confronted with the question "Is Client/Server computing cheaper?" McCarthy et al. 3 pre- sent the costs involved in a CSS sys- tem and compare it to the typical costs of a mainframe-centric (or time-shared system centric) appli- cation. They have broken down the life cycle cost of a CSS into five cate- gories and forecast the cost of developing an application based on the Client/Server computing model, as opposed to the time- sharing model shown in Table 1. Thus, they summarize: • Time-sharing has the edge in application development cost through 1992 due to (1) incomplete and incompatible development tools in Client-Server environment and (2) additional complexity of building and testing split applica- tions. • CSS holds a hardware cost advan- tage over minicomputers. • System administration is more difficult in a CSS, since (1) the man- agement tools are immature or 80 July 1992/Vol.35, No.7/COMMUNIGATIONS OF THE ACM
`
`

`

`missing, (2) a CSS composite con- sists of nmltivendor-supplied com- ponents, (3) Time-sharing systems allow central administration. • Software maintenance in a CSS is expected to be lower than in a time- sharing system due to (1) greater reliance on packages as opposed to in-house developments, (2) utiliza- tion of new software technology such as object-oriented program- ming. 5 • Adoption of the graphical user interface in a CSS will help cut user training costs by as much as 30 to 40%. Technology The major components of a Client- Server System are: • LAN: This is the backbone of the communication subsystem of a CSS and provides low-level communica- tion mechanisms to the network applications. • LAN-based PC Servers: The Server can be either a packaged product (e.g., file Server, database Server) or a custom-designed Server to meet the needs of the business. • Mainframe connectivity via PC Server, if desired: This gives the Clients easy access to the vast re- sources of the existing mainframes. This feature is crucial to the success of a CSS, since it provides a natural migration path to the users and applications downsized from the mainframes. • Higher-level connectivity support (e.g., RPC) and Client-Server dia- logue (e.g., SQL) support • GUI. While the Client-Server paradigm itself is not new to the computer industry, it is only now that most of the components of a CSS are com- mercially available. With the emer- gence of industry standards in user interfaces such as Microsoft Win- dows, OSF Motif, IBM Presentation Manager, the development of the Client software has become rela- tively simple and less time-consum- ing; these new interfaces, however, have caused escalation of developer training costs. Similarly, LAN software vendors have provided higher-level com- munication support. This has been a catalyst in rapid development of the Client-Server systems. The high-level interfaces present a less daunting task of developing and. testing the communication subsys- tems, and allow simpler designs. Connectivity Interfaces Low-Level Methods. Traditionally, the emphasis of most early LAN software systems (e.g., Microsoft MS-Net) was on providing such ser- vices as file-Sharing and printing. Thus they provided limited and low-level programming interfaces for the LAN system. For backward compatibility reasons, these inter- faces are present in the most evolved (or advanced) versions of the corresponding LAN software systems. Most applications which used (or use) these methods have long de- velopment and testing cycles. Soft- ware maintenance and portability of these applications are arduous at best. Furthermore, these necessi- tate business houses to train their programmers to be specialized net- work programmers. Due to low overhead, however, associated with the transport mechanism itself, high data transmission throughput Network Basic Input/Output Sys- tem (NetBIOS). This was originally developed by Sytek, Inc. as a "high- level" programming interface to the IBM PC Network on a broad- band adaptor card in August 1984. It was located on the IBM PC Net- work LAN Adaptor (LANA) as an "extention" to B1OS ROM. Soon, it became a &facto session layer stan- dard for the PC LAN industry. In the 1984-85 year, Microsoft devel- oped Microsoft Network (MSNet) software for IBM based on Net- BIOS, which formed the basis of a wide array of LAN software sys- tems. Most noticeable were IBM PCLP, original versions of DEC Pathworks and UB Net/One, and 3corn 3+Share. NetB1OS represents a program- ming interface at the Session Layer as per the OSI model 6 (Figure 3). The programming interface and some implementation specifications have been defined by IBM 9, leav- ing implementation details to each vendor. Currently, NetBIOS sup- port is provided by all major LAN vendors (e.g., Novell, Microsoft, Banyan) on DOS, Windows, OS/2, and Unix platforms. Applications interact with Net- BIOS support through a data struc- ture called Network Control Block (NCB) (see Figure 4); An applica- tion must specify values for Com- mand field and may specify values for zero or more fields in the NCB data structure, depending on the NCB Command. Finally, an appli- cation "submits" a NCB to the Net- BIOS support. The exact interface varies with operating system e.g., while in the DOS environment, an application can call function INT 5provided object-oriented tools are available can be achieved in each case. Table 1. Relative Cost of Development of a Client/Server System as Compared to a Time-Shared System. COSt Category Application Hardware Systems Software Year Development Acquisition Administration Maintenance Training 1990 + 30% - 20% + 30% 0% + 10% 1992 + 10% - 30% + 20% - 10% 0% 1994 - 10% - 40% + 10% - 25% + 10% 6See Tanenbaum, A. S. Computer Networks, Prentice-Hall, Englewood Cliffs, N.J. 07632 1980, for a detailed explanation of the OSI layers. COMMUNICATIONS OF THE ACM/July 1992/Vol.35, No.7 81
`
`

`

`Offset +00 +01 +02 +03 +04 +08 +10 +26 +42 +43 +44 +48 +49 +50 Layer 7 6 5 4 3 2 1 Application 3 Presentation " Session Transport - Network Data Link Physical " Field Name The NCB Fields Length in Byl:es Command 1 Return Code 1 Local Session Number 1 Name Number 1 Buffer Address 4 Buffer Length 2 Call Length 16 Name (Local) 16 Receive Time Out 1 Send Time Out 1 Post Routine Address 4 LANA Number 1 Command Complete Flag 1 Reserved Field 14 Figure 3. OSl model and different in- terfaces Figure 4. NetWOrk control block (NCB) data structure 5C with the address of NCB in reg- ister pair ES:BX to "submit" a NCB; in the OS/2 environment, an application calls NetBiosSubmit0 function to "submit" a NCB. In all cases, the underlying NetBIOS support program returns a success or failure message in the Return Code field of NCB. Almost all NCB commands can be executed either synchronously or asynchronously. NetBIOS provides two kinds of data transfer methods--session support and datagram support. Session support provides a reliable data transfer mechanism and flexi- Application Layer Interfaces (Named Pipe, TLI, Mail SIot) NetBIOS SPX Sockets IPX Field Structures ~QOQ DO OQDOOQDOODQQDDOQ DDOODQODOOODOQDO ODDD ODDDDQDDDDODDD bility to the applications to establish up to 254 sessions per LAN adaptor per network node (Session number 0 and 255 are reserved). If the data cannot be transferred reliably, an error code is returned to the appli- cation program through NCB. Datagram support provides the "best effort" data transfer mecha- nism, and receipt of data is not guaranteed 9. Furthermore, NetBIOS provides Name Support to the application programs as well, so that a network node can be addressed-- individually by a 16-byte unique name or as a group by a 16-byte group name. Every LAN adaptor has a unique 6-byte permanent name (provided by the adaptor manufacturer), which is appended with 10 bytes of binary zeros to form the first name in the Name Table maintained by every LAN adaptor. Applications can add up to 254 additional names per adaptor per network node. NetBIOS pro- vides a name-resolution protocol to check that a unique name to be added in an adaptor Name Table is not used by any other adaptor on the network and a group name is not present as a unique name in any adaptor on the network 9. Appli- cations can thus use unique names or group names to communicate with one other. Internetworking is hidden from applications by underlying Net- BIOS drivers or programs and bridges which together provide Source Routing of packets. 7 Simply put, Source Routing is a protocol in which a sender node specifies the route (through LANs and bridges) to the destination node in the frame itself. A route consists of a sequence of route designators, each compris- ing a LAN number and an adja- cent-next-bridge number 16. The route is carried in the routing in- formation field, distinct from the address field that includes control information. A bridge scans the routing information field for its bridge number sandwiched be- tween the two LANs it joins. The routing information is acquired by the network nodes dynamically with the cooperation of bridges. A simple Client-Server System consists of a Server which will wait, "listening" (NetBIOS command: NCB_LISTEN) to a 'Call' (Net- BIOS command: NCB_CALL) from any Client. Once a 'Listen' matches a 'Call', a session is set up between the Server and the Client. Now, the Server and the Client can transfer data (up to 64KB) bidirec- tionally through NetBIOS data transfer commands, such as NCB_SEND and NCB_RECEIVE. 7A bridge between two local area networks copies some or all packets from one net to another and vice-versa. A bridge operates a data link layer of the OSI model. An intelli- gent bridge uses intelligent and efficient packet transfer methods instead of transfer- ring all packets from one net to another and vice-versa. 82 July 1992/Vol.35, No. 7/COMMUNICATIONS OF THE ACM
`
`

`

`Finally, either end can break the session using NCB_HANGUP com- mand. NetBIOS provides a solid back- ward and forward compatible com- munication method which is a de facto standard in PC LANs. It gives an efficient and fast means of trans- ferring data peer-to-peer or Client to Server. However, it causes long product development, testing, and maintenance cycles as most often, it requires low-level debugging using network packet analyzers. Internetwork Packet Exchange (IPX) and Sequenced Packet Ex- change (SPX). These protocols were introduced by Novell in their NetWare LAN products. It is now available in a number of LAN soft- ware environments as an added feature for allowing NetWare con- nectivity and interoperability. IPX protocol is the native communica- tion protocol of NetWare itself and is recommended by Novell as the communication method for Client- Server applications 14. The IPX protocol is an implementation of the Internetwork Datagram Packet (IDP) Protocol designed by Xerox Corporation. It is essentially a data- gram delivery service 15. On the other hand, SPX protocol is a guar- anteed delivery service. Thus, the IPX programming interface ex- poses an interface at the network layer and SPX programming inter- face at the session layer (Figure 3). An IPX packet is identical to a Xerox Internetwork Standard (XNS), which consists of a 30-byte header followed by 0 to 546 bytes of data (Figure 5). A message can be sent to any node on the internet- work by placing it in the data por- tion of the IPX packet. Each packet must have the destination address, which is composed of the tuple {destination network, node, socket}. The destination network, or destNet in IPX structure, is a 4-byte number specifying a LAN number and is 0 for a node on the same LAN as the sender. The destination node, of destNode in an IPX struc- ture, is a 6-byte number which con- tains the physical address of the destination node (LAN adaptor) and can be set to 0x FF FF FF FF FF FF for sending a broadcast packet. Finally, a destination socket, or destSocket in IPX header, is a 2-byte field containing the socket address of the destination process. A SPX packet contains an addi- tional 12 bytes of header to keep track of the packet sequence and acknowledgment number, and may thus contain up to 534 bytes of data. Applications sending SPX packets form SPX connections with destination applications, and SPX retransmits any unacknowledged packets after appropriate timeout intervals. After a certain number of unacknowledged retransmissions, SPX assumes that destination appli- cation is no longer listening and breaks the connection 15. Applications communicate with one another, using either an IPX or SPX programming interface. Prior to using either IPX or SPX func- tions, applications must prepare and set up a structure called Event Control Block (ECB). Then, they can call the IPX, SPX functions with pointers to ECB, which con- tains the address of the IPX or SPX packet itself. A typical Client-Server System consists of a Server that will "open" a socket (Novell IPX API: IPX OpenSocket) and wait to "receive" a packet from any Client (Novell IPX API: IPXReceive). The Server must also "advertise" its presence (Novell Bindery API: Ad~ ertiseSer- vice) so that when a Client wishes to connect to a server, it can "seek" a Server (Novell Bindery API: Scan- Bindery) and determine the Serv- er's address (Novell IPX command: IPXGetLocal Target). Finally, the Client can "send" a request to the Server (Novell IPX API: IPXSendPacket). Novell also pro- vides IPX Setup API, which fills in other necessary fields of the ECB. IPX provides a fast and efficient communication interface due to lit- tle overhead associated with each packet and to its being a simple datagram protocol. SPX provides a stable connection-oriented commu- nication interface which gains in speed due to tight integration with IPX. Both IPX and SPX, however, suffer from the drawback of being low-level programming, similar to the NetBIOS interface. Sockets. These are the building blocks of communication in the Berkeley Unix system and were first introduced in 4.3BSD as an improvement or generalization of pipes. Pipes provide IPC mecha- nisms on the same system. Socket is Figure S. Ipx/spx Docket structure IPX Packet Structure unsigned short checksum; P high-low */ packetLen packetLen; P high-low */ unsigned char transportCtl; unsigned char packetType; unsigned long destNet; P high-low */ unsigned char destNode6; P high-low */ unsigned short destSocket; P high-low */ unsigned long source Net; P high-low */ unsigned char soumeNode6; P high-low */ unsigned short soumeSockat; P high-low */ The SPX packet header consists of an IPX header (30 bytes) and seven additional fields as follows: unsigned char connectionCtl; unsigned char dataStreamType; unsigned short sourceConnectlD; P high-low */ unsigned short destConnectlD; P high-low */ unsigned short sequenceNumber;, P high-low */ unsigned short ackNumber; P high-low */ unsigned short allocNumber;, P high-low */ COMMUNICATIONS OF THE ACM/July 1992/Vol.35, No.7 83
`
`

`

`an endpoint of communication to which a name can be "bound" 11. Each socket in use has a "type" and has one or more processes attached to it. The "type" of socket deter- mines the method and mode of data transfer in the socket as shown: • Stream Socket: provides bidirec- tional, reliable, sequenced, and unduplicated flow of data without record boundaries • Sequenced Packet Socket:: pro- vides bidirectional, reliable, se- quenced, and unduplicated tow of data with record boundaries • Datagram Socket: provides unre- liable packet transfer across the socket. • Raw Socket: provides access to underlying communication proto- col and is provided so sophisticated Internet applications can be devel- oped In a sockets environment, the Client (s) as well as the Server must first create a socket by some appro- priate socket interface call (4.3BSD call: socket ()). One needs to specify the tuple { domain, type, protocol} when creating a socket. The "type" of a socket has been discussed. One can specify a specific communica- tion domain, e.g., an intra-system domain (in 4.3BSD: AF_Unix), or Internet domain (in 4.';BSD: AF_INET). Furthermore, one can either use the default communica- tion protocol (e.g., TCP/IP) or spec- ify a specific protocol (e.g., "myprotocol"). A socket by itself is nameless, and thus, it cannot be addressed or ref- erenced. In order for Internet communication to take place, there must be an "association" between communicating processes, which is of form {local pathname:local port::foreign pathname:foreign port}. On the other hand, an associ- ation {local pathname::foreign pathname} is sufficient for intra- system processes (where 'fi)reign pathname' means a pathname cre- ated by foreign processes, not a pathname on a foreign system) 11. In order for this association to be built, the Server must call bind interface {4.3BSD call: bind (sock- et_no, local name, name length)}. Furthermore, the Server must issue a 'listen' call (4.3 BSD call: listen (socket__no, maximum number of outstanding connections)}. Fur- thermore, it must also make 'accept' or 'select' {4.3BSD call: accept (soc- ket__no,..) or select(...) } calls to listen for Client request to connect; 'se- lect' provides a synchronous input/ output request. The association is completed when a Client makes a 'connect' call {4.3 BSD call: connect (sockeLno, server address, size of address)}. The Client must either know the Server address, or it may use socket interface library along with Name Service to obtain the address of the Server. Now, the Client and the Server can transfer data by means of 'read/write' calls {4.3BSD: write(socket__no, buffer, size of buffer) and read(socket__no, buffer, size of buffer)}. Finally, they can eliminate the connection by means of 'close' {4.3 BSD: close(sock- eL_no)} function