Dr M Dakshayini Professor Dept of ISE BMSCE Bangalore 41 Introduction Previous chapters describe the clientserver model of interaction for communicating programs and discuss the relationship between concurrency and communication ID: 1003074
Download Presentation The PPT/PDF document "Program Interface To Protocols" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
1. Program Interface To ProtocolsDr. M Dakshayini,Professor, Dept. of ISE, BMSCE, Bangalore
2. 4.1 IntroductionPrevious chapters describe the client-server model of interaction for communicating programs and discuss the relationship between concurrency and communication.This chapter considers general properties of the interface an application program uses to communicate in the client-server model. The following chapter illustrates these properties by giving details of a specific interface.
3. Application 1Socketsocket interfaceuserkernelApplication 2userkernelUnderlying communication ProtocolsUnderlying communication ProtocolsCommunications network Socketsocket interfaceApplication Program interface/Socket Interface.
4. 4.2 Loosely Specified Protocol Software InterfaceIn most implementations, TCP/IP protocol software is present in the computer’s operating system. So, whenever an application program wants to use TCP/IP to communicate, it must interact with the operating system to request service. From a programmer’s point of viewthe routines the operating system supplies define the interface between the application and the protocol software - the application interface.
5. TCP/IP was designed to operate in a multi-vendor environmentTCP/IP designers carefully avoided choosing any vendor’s internal data representation.Thus TCP/IP is compatible with a wide variety of machinesIn addition, the TCP/IP standards carefully avoid specifying the application available only on a single vendor’s operating system. Thus, the interface between TCP/IP and applications that use it has been loosely specified.
6. The TCP/IP standards do not specify the details of - how application software interfaces with TCP/IP protocol softwarethey only suggest the required functionality, and allow system designers to choose the details.
7. 4.2.1 loose specification for the protocol interface - Advantages And Disadvantages On the positive side, it provides flexibility and tolerance. It allows designers to implement TCP/IP using operating systems that range from the simplest systems available on personal computers to the sophisticated systems used on supercomputers. It means designers can use either a procedural or message-passing interface style (whichever style the operating system supports).
8. On the negative side, a loose specification means - designers can make the interface details different for each operating system. As vendors add new interfaces that differ from existing interfaces, application programming becomes more difficult and applications become less portable across machines. Thus, while system designers favor a loose specification, application programmers desire a restricted specification because it means applications can be compiled for new machines without change.
9. In practice, only a few TCP/IP interfaces exist. The University of California at Berkeley defined an interface for the Berkeley UNIX operating system - socket interface, or sockets. AT&T defined an interface for System V UNIX - acronym TLI. A few other interfaces have been defined, but none has gained wide acceptance yet.
10. 4.3 Interface FunctionalityTCP/IP does not define an application program interface - the standards - suggest the functionality needed. An interface must support the following conceptual operations:Allocate local resources for communication Specify local and remote communication endpoints and Initiate a connection (client side)Wait for an incoming connection (server side) Send or receive data Determine when data arrives Generate urgent data Handle incoming urgent data Terminate a connection gracefully Handle connection termination from the remote site Abort communication Handle error conditions or a connection abort Release local resources when communication finishes
11. 4.4 Conceptual Interface SpecificationThe TCP/IP standards specify a conceptual interface for TCP/IP that serves as an illustrative exampleBecause most operating systems use a procedural mechanism to transfer control from an application program - > into the system, the standard defines the conceptual interface as a set of procedures and functionsthe parameters that each procedure or function requires as well as the semantics of the operation it perform.illustrates loosely how applications interact with TCPdoes not specify data representations or programming details; For example, the TCP standard discusses a SEND procedure, and lists the arguments an application needs to supply to send data on an existing TCP connection.
12. 4.5 System CallsFigure illustrates the system call mechanism that most operating systems use to transfer control between an application program and the operating system procedures that supply services. To a programmer, system calls look and act like function calls.
13. As the figure shows, when an application invokes a system call, control passes from the application to the system call interface. The interface then transfers control to the operating system. The operating system directs the incoming call to an internal procedure that performs the requested operation. Once the internal procedure completes, control returns through the system call interface to the application, which then continues to execute. In essence, whenever an application program needs service from the operating system, the process executing the application climbs into the operating system, performs the necessary operation, and then climbs back out. As it passes through the system call interface, the process acquires privileges that allow it to read or modify data structures in the operating system. The operating system remains protected, however, because each system call branches to a procedure that the operating system designers have written.
14. 4.6 Two Basic Approaches To Network CommunicationOperating system designers must choose the exact set of procedures used to access TCP/IP protocols when they install protocol software in an operating system. Implementations follow one of two approaches:The designer invents entirely new system calls that applications use to access TCP/IP. The designer attempts to use conventional I/O calls to access TCP/IP.
15. In the first approach, the designer makes a list of all conceptual operations, invents names and parameters for each, and implements each as a system call. Because many designers consider it unwise to create new system calls unless absolutely necessary, this approach is seldom used. In the second approach, the designer uses conventional I/O primitives but overloads them to work with network protocols as well as conventional I/O devices. many designers choose a hybrid approach that uses basic I/O functions whenever possible, but adds additional functions for those operations that cannot be expressed conveniently.
16. 4.7 The Basic I/O Functions Available In UNIXTo understand how conventional system calls can be extended to accommodate TCP/IPUNIX (and the many OS variants derived from it) provides a basic set of six system functions used for input/output operations [UNIX I/O functions] on devices or files. The table in Figure 4.2 lists the operations and their conventional meanings.open Prepare a device or a file for input or output operationsclose Terminate use of a previously opened device or fileread Obtain data from an input device or file, and place it in theapplication program’s memorywrite Transmit data from the application program’s memory to anoutput device or file lseek Move to a specific position in a file or device (this operationonly applies to files or devices like disks)ioctl Control a device or the software used to access it(e.g., specify the size of a buffer or change the characterset mapping) - Input Output Control.
17. When an application program calls open to initiate input or output, the system returns a small integer called a file descriptor that the application uses in further I/O operations. The call to open takes three arguments: the name of a file or device to open, a set of bit flags that controls special cases such as whether to create the file if it does not exist, and an access mode that specifies read/write protections for newly created files. For example, the code segment: int desc; desc = open("filename", O_RDWR, 0)opens an existing file, filename, with a mode that allows both reading and writing.After obtaining the integer descriptor, desc, the application uses it in further I/O operations on the file. For example, the statement: read(desc, buffer, 128);reads 128 bytes of data from the file into array buffer.Finally, when an application finishes using a file, it calls close to deallocate the descriptor and release associated resources (e.g., internal buffers): close(desc);
18. 4.8 Using UNIX I/O With TCP/IPWhen designers added TCP/IP protocols to UNIX, they extended the conventional UNIX I/O facilities. First, they extended the set of file descriptors and made it possible for applications to create descriptors used for network communication. Second, they extended the read and write system calls so they worked with the new network descriptors as well as with conventional file descriptors. Thus,when an application needs to send data across a TCP connection, it creates the appropriate descriptor, and then uses write to transfer data.
19. However, not all network communication fits easily into UNIX’s open-read-write close paradigm. An application must specify the local and remote protocol ports and the remote IP address it will use, whether it will use TCP or UDP, and whether it will initiate transfer or wait for an incoming connection (i.e., whether it wants to behave as a client or server). Furthermore, if an application chooses to use UDP, it must be able to transfer UDP datagrams, not merely a stream of bytes. If it is a server, it must specify how many incoming connection requests the operating system should enqueue before rejecting them. The designers of Berkeley UNIX added new system calls to UNIX to accommodate these special cases. The next chapter shows the details of the design.
20. Acknowledgements