Linux Socket Programming by Example PHẦN 4 ppt

From the session shown, you can see that the client program prompts you for input. The first input was just the simple pair of characters %D and a RETURN. The result came back from the server as '08/13/99'. Note that the socket address of the datagram sender was reported, and it agreed with the server address that was expected (the program default). Another input of %A %D %H:%M:%S was tried with the server returning the result of 'Friday 08/13/99 22:14:02'. Finally, the input quit was provided, and both the client program and the server program exited. Testing with No Server The following shows what happens when the client program is run, and no server is running: $ ./dgramclnt Enter format string: %D Connection refused: recvfrom(2) $ Note that the client program is able to start up, create the socket, and ask for input. Even the sendto(2) function was reported as successful (the error message came from the recvfrom(2) statement which follows the call to sendto(2)). This confirms the fact that sending a datagram only confirms that it was sent out—not that it was successfully received. In this particular situation, the program was lucky enough to get an error response to indicate that no server was listening on that address and port. The error indication was picked up by the recvfrom(2) function call. When the client and server are separated by a large network and many routers, this error indication may not always be received. In practice, you cannot rely on getting the error if the other end is not listening. For this reason, UDP programs often include the use of timers, and assume that no contact was made if no response is received within a certain amount of time. Testing with Other IP Numbers In the preceding sections, it was mentioned that an IP number could be given on the command line. If you have your own network set up, you can try running the client and server programs on different hosts. In the next example, the server Linux Socket Programming by Example - Warren W. Gay 155 will be started on host 192.168.0.1, and the client program will be run from 192.168.0.2. The following shows the server startup: $ ./dgramsrvr 192.168.0.1 & [1] 4416 $ With the server successfully started up, the client program is invoked on the other host. The following session shows the output seen from the client end: $ ./dgramclnt 192.168.0.1 Enter format string: %D Result from 192.168.0.1 port 9090 : '08/13/99' Enter format string: %A (%D) Result from 192.168.0.1 port 9090 : 'Friday (08/13/99)' Enter format string: QUIT $ As shown, the client program was told that the server was located at address 192.168.0.1 by providing the address on the command line. A couple of examples were tried, and then the QUIT command was given. The pair of programs demonstrated themselves as working correctly. While this example shows flawless execution, keep in mind that UDP is unreliable. If the client program fails to get a response from the server, it will hang (at line 111 in Listing 6.2). If you were writing a production mode application, you'd need to provide code for a timeout. This would allow the program to recover from the lack of a response when the original or response datagrams are lost. Leaving Out bind(2) in Client Programs Some observant readers might have noticed that no call to bind(2) was made in the client program for the socket that was created in Listing 6.2. If the bind(2) function call can be eliminated, then why bother with it at all? You'll remember that in Chapter 5, "Binding Addresses to a Socket," there was a section titled "Interfaces and Addressing" Linux Socket Programming by Example - Warren W. Gay 156 which explained that the bind(2) function could be used to restrict the interfaces that would be used to perform communications. The example used in Figure 5.1 was a firewall application program that only wished to communicate with a trusted internal network. If this seems vague to you right now, you might want to turn back there and review how bind(2) accomplished this. In Listing 6.2, the call to bind(2) was omitted. So what does this omission imply for the sending socket? As you know from Chapter 5, this actually indicates that the program will accept any outgoing interface, as required by the routing of the datagram to its destination. In effect, the socket is said to have a wild socket address. Later, when the program waits for a response, it will accept an input datagram from any incoming interface as well. Note also that this socket's port number is also wild. In this particular application, any client port number is acceptable. You can explicitly request a wild address and port with a call to bind(2). Listing 5.6 showed you how this was done by using the wild address INADDR_NONE. To request a wild port number, the port number is given as zero. By combining INADDR_NONE for the IP number and a port number of zero, you have requested that bind(2) give you the same wild address explicitly that you would have used without a call to bind(2). Replying to a Wild Address If the client program's address and port number are wild, you might wonder how the server was able to reply to that particular socket. After all, how do you write a response back to the client without a specific IP address and UDP port number? The answer to this question lies in the fact that an IP number and port number are assigned at the time the datagram is sent. The previous session shown occurred on the host with an IP number of 192.168.0.2. When the client program called the sendto(2) function, the datagram was known to be destined for host IP number 192.168.0.1. The routing tables indicated that the Ethernet interface with IP number 192.168.0.2 would be used to send the datagram to that host. Consequently, the sending datagram had a "from" address of 192.168.0.2. This was the address seen at the server end. The port number, however, was wild and would have been chosen as any one of the free port numbers for the IP number chosen. Linux Socket Programming by Example - Warren W. Gay 157 If another datagram is destined to a different network, then its "from" IP number will be different again. The "from" address will reflect the IP number of the network interface used to send the datagram. This is an important concept to grasp and is perhaps one of the most difficult things for the beginner to grapple with. If your understanding is not yet complete on this, you should review Chapter 5 until you have a thorough understanding. As an exercise, you can add the following printf(3) statement to the server in Listing 6.1, immediately after the recvfrom(2) function call (after line 107): printf("Client from %s port %u;\n", inet_ntoa(adr_clnt.sin_addr), (unsigned)ntohs(adr_clnt.sin_port)); With this line added, perform the following steps: 1. Kill or take down the existing server(s) if it (they) are still running. 2. Recompile the server dgramsrvr. 3. Restart the server (on 192.168.0.1, for example). 4. Run the client program again (from 192.168.0.2, for example). The following line was displayed when the client on 192.168.0.2 sent the server on 192.168.0.1 a datagram: Client from 192.168.0.2 port 1026; This confirms the fact that an IP number was assigned at the client end, and the port number assigned was 1026 in this example. This information enabled the server to direct its response back to the original requesting client. If you lack a network, you can still perform this experiment on your standalone PC. First, start the server, using its default address: $ ./dgramsrvr & Now run your client program: $ ./dgramclnt Linux Socket Programming by Example - Warren W. Gay 158 The output of your server program and client program will mix if run from the same terminal window (you can, however, run them from separate windows if you like). The following session shows the server and client output, when they are run on a single standalone PC, within the same terminal window. $ ./dgramsrvr & [1] 733 $ ./dgramclnt Enter format string: %D Client from 127.0.0.23 port 1027; Result from 127.0.0.23 port 9090 : '08/15/99' Enter format string: %A %D Client from 127.0.0.23 port 1027; Result from 127.0.0.23 port 9090 : 'Sunday 08/15/99' Enter format string: QUIT Client from 127.0.0.23 port 1027; [1]+ Done ./dgramsrvr $ Notice that for all datagrams sent to the server, the datagram from address was reported as Client from 127.0.0.23 port 1027; Again, this confirms that the correct IP address and a final port number are assigned upon demand, whenever bind(2) is not used on the client's sending socket. What's Next This chapter introduced you to the concept of connectionless- and connection-oriented communication. The UDP protocol was used to explore and demonstrate this connectionless mode of communication. You have demonstrated your ability to write a client and server program using the UDP network protocol. Don't stop here, however, because UDP isn't always the best choice for applications. The next chapter will show you another mode of communication for client and server. There you will learn about the connection Linux Socket Programming by Example - Warren W. Gay 159 mode of communication using a TCP/IP client program. So, hang onto your red hat! Chapter 7. Connection- Oriented Protocols for Clients You'll recall from the last chapter that there are two basic modes of communication for sockets. They are connection and connectionless modes of communication. In the last chapter, you also saw how the UDP protocol could be used to communicate in a connectionless fashion. In this chapter, you'll put the TCP/IP protocol to use, using a connection-oriented form of communication. This chapter will introduce you to • The advantages of connection-oriented protocols • The /etc/services file and its support routines • The /etc/protocols file and its support routines • The connect(2) function • How to write a TCP/IP client program Before you jump in and write your first client program, however, a quick review and an introduction to connection-oriented communications is in order. Additionally, you'll learn about some of the support functions that are often used by TCP/IP programs that locate service and protocol information. Reviewing the Methods of Communication It was also noted in the last chapter that connectionless- oriented communication is simpler and more flexible. But you'll see that connection-oriented communication is not really that much more difficult. It does require additional steps, however, and mostly on the server side. A connection is also much more rigid, because after the connection has been established, the socket can only communicate with the connected endpoint. The selling point in favor of TCP/IP for most application writers is that the communication channel is transparently reliable and that data is delivered in the proper sequence. After the connection has been established, your application can read and Linux Socket Programming by Example - Warren W. Gay 160 write to the socket without worrying about any of the following problems: • Lost packets • Timeouts and retransmissions • Duplicated packets • Packets received out of sequence • Flow control Like opening a file, your program can 1. Establish a TCP/IP connection with a remote socket 2. Transmit large amounts of data 3. Close the socket These simple steps are all that is necessary to deliver all of your data safely to the remote end. Proven error recovery software will take care of retransmitting lost packets until they can be successfully delivered to the remote host. TCP/IP Handles Lost Packets TCP/IP will notice when packets are lost. This does not always happen with UDP. When packet errors are reported, the TCP/IP protocol can immediately respond with retransmissions. However, if an acknowledgement is missing, causing a timeout, the TCP/IP protocol takes steps to ensure that the data is retransmitted to its destination. Carefully crafted algorithms are used to make the transmission of the data nimble, without taxing the network capacity with retransmitted data. TCP/IP Handles Duplicated Packets Whenever a retransmission occurs, there is a slight possibility that more than one identical packet can be received at the remote end. If the retransmission occurs too early, for example, this can easily happen. The receiving end must be able to recognize this and discard extraneous packets. This is automatically performed by the TCP/IP protocol. TCP/IP Handles Sequencing When the volume of data requires multiple packets to be sent, there is a race to the finish line. The IP packet can be routed in different ways, according to dynamic routing and buffer Linux Socket Programming by Example - Warren W. Gay 161 congestion. This results in a race to the receiving end, where some packets can arrive ahead of other packets. For this reason, the receiving software must recognize this and sequence the data before presenting it to the application. Again, TCP/IP anticipates and corrects this problem. TCP/IP Handles Flow Control The ftp command uses TCP/IP to send and receive files. When you upload a large file to a remote ftp server, using the ftp send command, many data packets are placed on the network. It can happen that the receiving host can end up receiving packets faster than it can process them. The IP way of dealing with this problem is to discard these extra packets. TCP logically sits on top of the IP protocol like a layer (hence, it is called TCP/IP). It acts as a supervisor of sorts by ensuring that the receiving end is not overloaded with more data than it can handle. When the receiving end feels that it has enough data for the moment, it notifies the sending end not to send more data until further notice. When it catches up, the remote end will signal the sending end to start sending data again. This automatic throttling of data is known as flow control. Understanding the Advantages of TCP/IP The purpose of this introduction was to show you the advantage of using a connection-oriented protocol. TCP/IP is one such connection-oriented protocol, which you will explore in this chapter. You have seen the number of services it performs for you behind the scenes. This helps you to focus on your application programming, rather than network communication problems. Furthermore, because the same time-tested algorithms are at work for each program that uses TCP/IP, they perform in the same reliable manner. This allows you to focus on application program bugs instead. Internet Services Before you have fun working with TCP/IP in this chapter, you need to learn about some additional facilities as TCP/IP pertains to Internet services. Linux Socket Programming by Example - Warren W. Gay 162 Examining the /etc/services File Your Linux system has a text file, usually named /etc/services. This file is described in the man page services(5). This file maps the user-friendly names of certain Internet services to a port number and protocol. The precise pathname for this file is given by the C language macro _PATH_SERVICES. A simple example of its use follows: #include <netdb.h> printf("File is path '%s'\n", _PATH_SERVICES); The preceding code shows the necessary include file netdb.h and a printf(3) statement, which prints out the pathname for the services file. Each text line in the /etc/services file describes one Internet service. It has the following general format: service-name port/protocol [alias …] The square brackets shown indicate that the one or more alias entries are optional. The /etc/services text line is described in detail in Table 7.1. Table 7.1. The /etc/services Fields Field Description service- name The case-sensitive user-friendly name of the service is described by this table entry. port The port number precedes the slash, and is the decimal port number for the service. / This separates the port number from the protocol field. protocol This specifies the type of the protocol to be used. This should be a protocol that can be found in the protocols(5) file. Common examples are udp or tcp. alias Other names for the "service-name." Additional aliases can be separated by tabs or spaces. There is a maximum of 35 aliases permitted, due to restrictions in getservent(3). Following is a pair of well-known service entries: Linux Socket Programming by Example - Warren W. Gay 163 ftp 21/tcp telnet 23/tcp The first entry shown lists the ftp service as being available on TCP/IP port 21. The second entry shows the telnet service being available on TCP/IP port 23. Working with the /etc/services file directly is neither convenient nor wise for your program. Consequently, Linux provides you with some routines to make things easier. Using Function getservent(3) If you have used some of the password database functions like getpwent(3) before, the functions about to be described here will seem similar. The synopsis of the getservent(3) function is as follows: #include <netdb.h> struct servent *getservent(void); For each call to getservent(3), you are returned a pointer to a structure that represents one entry from the /etc/services file. When the end-of-file is reached, a NULL pointer is returned (but see the caution that follows). If an error occurs, a NULL pointer is also returned, with the reason for the error posted to variable errno. Caution Even when the value of errno is zeroed prior to calling getservent(3), when end-of-file is reached and indicated by a NULL return pointer, the errno value for Red Hat Linux 6.0 is code ENOENT. Under other UNIX operating systems, such as HP-UX 10.2 and Sun Solaris 5.5.1, the errno value is left at zero when end-of-file is returned. This leads the author to speculate that this behavior is a bug, which might be corrected in a later release of Linux. When the pointer returned is not NULL, it points to the structure servent, as illustrated in Listing 7.1. Linux Socket Programming by Example - Warren W. Gay 164 [...]... AF_INET */ 34: int len_inet; /* length */ 35: int s; /* Socket */ 36: struct servent *sp; /* Service entry */ 37: char dtbuf[128]; /* Date/Time info */ 38: 39: /* 40 : * Use a server address from the command 41 : * line, if one has been provided 42 : * Otherwise, this program will default 43 : * to using the arbitrary address 44 : * 127.0.0.1: 45 : */ 46 : if ( argc >= 2 ) { 47 : /* Addr on cmdline: */ 48 : srvr_addr... INADDR_NONE ) 74: bail("bad address."); 75: 76: len_inet = sizeof adr_srvr; 77: 78: /* 79: * Create a TCP/IP socket to use: 80: */ 81: s = socket( PF_INET,SOCK_STREAM,0); Linux Socket Programming by Example - Warren W Gay 180 82: 83: 84: 85: 86: 87: 88: 89: 90: 91: 92: 93: 94: 95: 96: 97: 98: 99: 100: 101: 102: 103: 1 04: 105: 106: 107: 108: 109: 110: 111: 112: 113: } if ( s == -1 ) bail( "socket( )"); /*... connections Linux Socket Programming by Example - Warren W Gay 1 84 The basic steps of the server can now be summarized as follows: 1 2 3 4 5 6 Create a socket Bind a socket address (mandatory) Listen for a connection Accept a connection Communicate with the client program Close the socket Notice that, for the server, the bind(2) step 2 (S2 in Figure 8.1) is not optional The server cannot be contacted by clients... #include int connect(int sockfd, struct sockaddr *serv_addr, int addrlen); This function takes three arguments They are 1 The socket file descriptor sockfd that was returned by a former call to socket( 2) Linux Socket Programming by Example - Warren W Gay 175 2 The server address serv_addr that the program is connecting to 3 The length addrlen of the server address in bytes The server... protoent.c—The getprotoent(3) Demo Program 1: 2: 3: 4: 5: 6: 7: 8: 9: /* protoent.c: * * Example getprotoent(3) program: */ #include #include #include #include #include Linux Socket Programming by Example - Warren W Gay 171 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 25: 26: 27: 28: 29: 30: 31: 32: 33: 34: 35: 36: 37: 38: 39: #include ... 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: /* servent.c: * * Example getservent(3) program: */ #include #include #include #include #include #include #include int main(int argc,char **argv) { int x; struct servent *sp; for (;;) { errno = 0; if ( !(sp = getservent()) ) Linux Socket Programming by Example. .. input argument is 6 (or the C macro constant IPPROTO_TCP), then you should get a structure pointer returned that has the value "tcp" in the member p_name Caution Linux Socket Programming by Example - Warren W Gay 1 74 The pointer returned by getprotobynumber(3) is only valid until the next call to the same function This brings you to the end of the getservent(3) and the getprotoent(3) function families Now... established in lines 67 to 76 Note especially line 69 where the service port number is established for the daytime service Linux Socket Programming by Example - Warren W Gay 181 4 The socket is created in line 81 Note especially the argument SOCK_STREAM that specifies that we want a TCP/IP socket (when used with PF_INET) 5 The program connects to the server in line 88 If this fails, the error is handled in... function can be used with UDP sockets (SOCK_DGRAM for protocol family PF_INET) This does not actually imply a connection, however, but instead imposes some restrictions upon how the UDP socket will be used This function call should be made 1 After the bind(2) function is called, if used 2 Before any datagrams are read or written on the socket Linux Socket Programming by Example - Warren W Gay 182 When... protocol 2 The protocol proto to be looked up for port Linux Socket Programming by Example - Warren W Gay 169 The function returns a NULL pointer if no service entry can be found to match your input parameters Otherwise, a pointer is returned to the structure containing information, such as the service name, for example Caution The pointer returned by getservbyport(3) is only valid until the next call to the . release of Linux. When the pointer returned is not NULL, it points to the structure servent, as illustrated in Listing 7.1. Linux Socket Programming by Example - Warren W. Gay 1 64 Listing 7.1. getservbyname(3) function does just that. The function synopsis is as follows: #include <netdb.h> Linux Socket Programming by Example - Warren W. Gay 168 struct servent *getservbyname(const. connection has been established, your application can read and Linux Socket Programming by Example - Warren W. Gay 160 write to the socket without worrying about any of the following problems: •