Client Server Computing

Transcription

1 Client Server Computing Although the Internet provides a basic communication service, the protocol software cannot initiate contact with, or accept contact from, a remote computer. Instead, two application programs must participate in any communication with one application initiates communication and the one accepts it. In network applications, a server application waits passively for contact after informing local protocol software that a specific type of message is expected, while a client application initiates communication actively by sending a matched type of message. 8/25/99 Socket API/ 1

2 Characteristics of Clients Software is an arbitrary application program that becomes a client temporarily when remote access is needed, but also performs other computation locally. is invoked directly by a user, and executes only for one session. runs locally on a user s personal computer. actively initiates contact with a server. can access multiple services as needed, but actively contacts one remote server at a time. does not require special hardware or sophisticated operating system. 8/25/99 Socket API/ 2

3 Characteristics of Servers Software is a special-purpose, privileged program dedicated to providing one service, but can handle multiple remote clients at the same time. is invoked automatically when a system boots, and continues to execute through many sessions. runs on a shared computer (i.e., not on a user s personal computer). waits passively for contact from arbitrary clients. accepts contact from arbitrary clients, but offers a single service. requires powerful hardware and a sophisticated OS. 8/25/99 Socket API/ 3

4 Identifying A Particular Service Transport protocols assign each service a unique identifier. Both client and server specify the service identifier; protocol software uses the identifier to direct each incoming request to the correct server. In TCP/IP, TCP uses 16-bit integer values known as protocol port numbers to identify services. 8/25/99 Socket API/ 4

5 Concurrent Server Concurrent execution is fundamental to servers because concurrency permits multiple clients to obtain a given service without having to wait for the server to finish previous requests. In concurrent server designs, the server creates a new thread to handle each client. Transport protocols assign an identifier to each client as well as to each service. Protocol software on the server s machine uses the combination of client and server identifiers to choose the correct copy of a concurrent server. 8/25/99 Socket API/ 5

6 The Socket API The interface between an application program and the communication protocols in an operating system (OS) is known as the Application Program Interface or API. Sockets provide an implementation of the SAP (Service Access Point) abstraction at the Transport Layer in the TCP/IP protocol suite, which is part of the BSD Unix. A socket library can provide applications with a socket API on an operating system that does not provide native sockets (e.g. Windows 3.1). When an application calls one of the socket procedures, control passes to a library routine that makes one or more calls to the underlying OS to implement the socket function. 8/25/99 Socket API/ 6

7 A socket may be thought of as a generalization of the BSD Unix file access mechanism (open-read-write-close) that provides an end-point for communication. When an application creates a socket, the application is given a small integer descriptor used to reference the socket. If a system uses the same descriptor space for sockets and other I/O, a single application can be used for network communication as well as for local data transfer. An application must supply many details for each socket by specifying many parameters and options (e.g. an application must choose a particular protocol, provide address of remote machine, specify whether it is a client or server, etc.) To avoid having a single socket function with separate parameters for each options, designers of the socket API chose to define many functions, each with a few parameters. 8/25/99 Socket API/ 7

8 Server (connection-oriented protocol) socket() bind() listen() accept() blocks until connection from client read() connection establishment data (request) Socket system calls for connection-oriented protocol Client socket() connect() write() process request write() data (reply) read() 8/25/99 Socket API/ 8

9 Server (connectionless protocol) socket() bind() recvfrom() Socket system calls for connectionless protocol Client socket() blocks until data received from client process request data (request) bind() sendto() sendto() data (reply) revfrom() 8/25/99 Socket API/ 9

10 Data communication between two hosts on the Internet require the five components of what is called an association to be initialized: {protocol,local-addr, localprocess, foreign-addr, foreign-process} The different system calls for sockets provides values for one or more of these components. 8/25/99 Socket API/ 10

11 Socket system call The first system call any process wishing to do network I/O has to call is the socket system call. int listenfd = socket (int family, int type, int protocol) Examples of Family include: PF_UNIX PF_INET Examples of Type include SOCK_STREAM SOCK_DGRAM SOCK_RAW The protocol argument is typically zero, but may be specified to request an actual protocol like UDP, TCP, ICMP, etc. Ideally, the three parameters should be orthogonal, but in reality, not all combinations are meaningful. 8/25/99 Socket API/ 11

12 The socket system call just fills in one element of the five-tuple we ve looked at - the protocol. The remaining are filled in by the other calls as shown in the figure. Connection-Oriented Server Connection-oriented Client Connectionless Server Connectionless Client protocol local_addr, local_process foreign_addr, foreign_process socket() bind() accept() socket() connect() socket() socket() bind() bind() recvfrom() sendto() 8/25/99 Socket API/ 12

13 Bind System Call The bind system call assigns an address to an unnamed socket. Example int bind(int listenfd, struct sockaddr_in *myaddr, int addrlen) What is bind used for? Servers (both connection oriented and connectionless) NEED to register their well-known address to be able to accept connection requests. A client can register a specific address for itself. A connectionless client NEEDS to assure that it is bound to some unique address, so that the server has a valid return address to send its responses to. 8/25/99 Socket API/ 13

14 The bind system call provides the values for the local_addr and local_process elements in the five_tuple in an association. An address for the Internet domain sockets is a combination of a hostname and a port number, as shown below: struct sockaddr_in { short sin_family ; /*typically AF_INET*/ u_short sin_port; /* 16 bit port number, network byte ordered */ struct in_addr sin_addr ; /* 32 bit netid/hostid, network byte ordered */ char sin_zero[8]; /* unused*/ } 8/25/99 Socket API/ 14

15 Connect/Listen/Accept System Calls Connect A client process connects a socket descriptor after a socket system call to establish a connection with the server. int connect(int listenfd, struct sockaddr_in *servaddr, int addrlen) For a connection-oriented client, the connect (along with an accept at the server side) assigns all four addresses and process components of the association. 8/25/99 Socket API/ 15

16 Listen The listen system call is used by a connection-oriented server to indicate it is willing to receive connections, e.g., listen(listenfd, qlength), where the system will enqueue up to qlength requests for connections. Accept After the server executes a listen, it waits for connection requests from client(s) in the accept system call, e.g., connfd = accept(listenfd, peer, addrlen) accept returns a new socket descriptor, which has all five components of the association specified - three (protocol, local addr, local_process) are inherited from the existing listenfd (which has its foreign address and process components unspecified, and hence can be re-used to accept another request. This scenario is typical for concurrent servers. ) 8/25/99 Socket API/ 16

17 Sending and Receiving Data Here s how you might read from a socket: num_read = read(listenfd, buff_ptr, num_bytes) And here s how you read from an open file descriptor in Unix: num_read = read(fildes, buff_ptr, numbytes) There are other ways (with different parameters) to send and receive data: read, readv, recv, recvfrom, recvmsg to receive data through a socket; and write, writev, send, sendto, sendmsg to send data through a socket. 8/25/99 Socket API/ 17

18 server {*.21, *.*} listening socket Figure 1. TCP concurrent server with a passive open on port client { , } Connection request to ,port 21 server {*.21, *.*} listening socket Figure 2. Connection request from client to concurrent server. 8/25/99 Socket API/ 18

19 client server { , } connection {*.21, *.*} fork listening socket server (child) { , } connected socket Figure 3. Concurrent server has child handle client. 8/25/99 Socket API/ 19

20 Connection-oriented Concurrent Server int listenfd, connfd; if ( (listenfd = socket(... )) < 0) err_sys("socket error"); if(bind(listenfd,... ) < 0) err_sys("bind error"); if(listen(listenfd, 5) < 0) err_sys("listen error"); for ( ; ; ) { connfd = accept(listenfd,... ); /*blocks */ if (connfd < 0) err_sys("accept error"); if (fork() == 0) { close(listenfd); /* child */ doit(connfd); close(connfd); exit(0); } close(connfd); /* parent */ } 8/25/99 Socket API/ 20

21 client connect( ) connection request server listenfd Figure 4. Status of client-server before call to accept. client connect( ) connection server listenfd connfd Figure 5. Status of client-server after return from accept. 8/25/99 Socket API/ 21

22 client server (parent) connect( ) connection listenfd connfd fork server (child) listenfd connfd Figure 6. Status of client-server after fork returns. 8/25/99 Socket API/ 22

23 client connect( ) server (parent) listenfd connection server (child) connfd Figure 7. Status of client-server after parent and child close appropriate sockets. 8/25/99 Socket API/ 23

24 Windows Sockets Windows sockets specification defines a network programming interface for Microsoft Windows which is based on BSD Unix Sockets. It has all the BSD Unix style socket routines, Database routines, and a set of windows-specific extensions. Windows Sockets Applications Programming Interface (Winsock API) is a library of functions (on Windows 3.1) or is a set of System Calls (on Windows 95 or Windows NT) that implement the socket interface as popularized by the BSD Unix. 8/25/99 Socket API/ 24

25 Winsock augments the Berkeley socket implementation by adding Windows specific extensions to support the message driven nature of Windows. Current version of Winsock is bound to the TCP/IP protocol suite. Future versions of Winsock are expected to support Novells IPX/SX, Apples Appletalk and other popular network protocols. We are particularly interested in the socket interface to TCP/IP protocol stack. 8/25/99 Socket API/ 25

26 Winsock specification allows TCP/IP stack vendors to provide a consistent interface to their stacks so that application developers can write an application to the Winsock specification and have that application run on any vendors Winsock compatible TCP/IP stack. Winsock API is built on top of Windows Socket DLL (Dynamic Link Library), which is built on top of the TCP/IP Protocol Stack API, which is typically proprietary. 8/25/99 Socket API/ 26

27 Deviation from Berkeley Socket There are some subtle differences between socket operations in Windows Sockets and regular UNIX based BSD Sockets. These can cause problems if you are not aware of them. Socket data type has been defined to enable the future usage of sockets as file handles in Windows NT environment. Additionally, whereas sockets on UNIX are file descriptors with a signed value, sockets in Windows Sockets are unsigned integers. In Berkeley sockets, they can be closed using close() call, whereas in Windows Sockets they are closed using closesocket() routine. 8/25/99 Socket API/ 27

28 In case of Berkeley sockets, by default, calls like recv are blocking calls if it is not specified by the programmer. These blocking calls are treated differently in Windows sockets. The Windows Socket DLL initiates the operation, and then enters a loop in which it dispatches any Window messages and then checks for the completion of socket calls. Winsock supports the TCP/IP domain for interprocess communication on the same computer as well as network communication. Sockets in most of the UNIX implementations support the UNIX domain of inter-process communication on the same computer and the Xerox XNS domain. 8/25/99 Socket API/ 28

29 Return values are different. For Example socket() function call returns -1 on failure in Unix environment and INVALID_SOCKET in WinSock implementation. In case of Windows socket programming, initially the underlying Windows Socket DLL should be initialized. This is done by command WSAStartup(). Any windows socket program should end with command WSACleanup(). Other differences include the select() API and error code retrieval. 8/25/99 Socket API/ 29

30 Winsock Extensions Most of the extensions to Winsock are due to the message-driven architecture of Microsoft Windows. Some of the extensions are also required to support the non-preemptive nature of 16- bit Windows 3.1 Operating System. 8/25/99 Socket API/ 30

31 Blocking versus non-blocking Many of the Berkeley Socket functions take an indeterminate amount of time. This is what it means by saying that a function is blocking. The calling function blocks the further execution of the program. This does not pose problems in UNIX environment because UNIX OS would simply preempt the blocking program and begin running another program. 8/25/99 Socket API/ 31

32 Windows 3.1 can not preempt a task. Because of this, all the other programs are put on hold until the blocking call returns. This is why Socket calls in Windows 3.1 have been designed to be non-blocking calls. This is where the socket calls use the message driven architecture of Windows operating system. The message queues of other applications were checked. This was not very efficient. 8/25/99 Socket API/ 32

33 Winsock Asynchronous functions There exists an implementation of nonblocking socket calls. Send can be implemented as both blocking and nonblocking call. If it is created in a blocking mode it would not return until data has been delivered. If it is created in a nonblocking mode it returns immediately and the program must call another function called select() to determine the status of send function call. 8/25/99 Socket API/ 33

34 This could be implemented similarly in Windows, but the best way to implement is by using special Windows asynchronous functions. The special Windows asynchronous functions begin with the prefix WSAAsync. The most common events to use these asynchronous functions are the send and receive events. Sending data may not happen instantly and the receiving is surely going to make a program wait. 8/25/99 Socket API/ 34

35 By creating a socket for nonblocking send and receive and using the WSAAsynSelect() function call, an application will receive event notification messages to inform it whether data has arrived or when it can send data. Winsock also uses a set of database functions. For Example, WSAAsyncGetXbyY (e.g.wsaasyncgethostbyname), which is a nonblocking function call, i.e., the application will be notified by message of the completion of the lookup. 8/25/99 Socket API/ 35