| 16-1. | Sockets. What is the difference between connection-oriented versus connectionless? |
| 16-2. | Client/Server Architecture. Describe in your own words what this term means and give several examples. |
| 16-3. | Sockets. Between TCP and UDP, which type of servers accept connections and hands them off to separate sockets for client communication? |
| 16-4. | Clients. Update the TCP (tsTclnt.py) and UDP (tsUclnt.py) clients so that the server name is not hard-coded into the application. Allow the user to specify a hostname and port number, and only use the default values if either or both parameters are missing. |
| 16-5. | Internetworking and Sockets. Implement Guido van Rossum's sample TCP client/server programs found in Section 7.2.2 of the Python Library Reference and get them to work. Set up the server, then the client. An online version of the source is also available here: http://www.python.org/doc/current/lib/ Socket_Example.html
You decide the server is too boring. Update the server so that it can do much more, recognizing the following commands: | | |
|---|
date | Server will return its current date/timestamp, i.e., time.ctime(time.time()) | os | Get OS info (os.name) | ls | Give a listing of the current directory (HINTS: os.listdir() lists a directory, os.curdir is the current directory.) Extra credit: Accept "lsdir" and return dir's file listing. |
You do not need a network to do this assignmentyour machine can talk to itself. Note: After the server exits, the binding must be cleared before you can run it again. You may experience "port already bound" errors. The operating system usually clears the binding within 5 minutes, so be patient! |
| 16-6. | Daytime Service. Use the socket.getservbyname() to determine the port number for the "daytime" service under the UDP protocol. Check the documentation for getservbyname() to get the exact usage syntax (i.e., socket.getservbyname.__doc__). Now write an application that sends a dummy message over and wait for the reply. Once you have received a reply from the server, display it to the screen. |
| 16-7. | Half-Duplex Chat. Create a simple, half-duplex chat program. By "half-duplex," we mean that when a connection is made and the service starts, only one person can type. The other participant must wait to get a message before he or she is prompted to enter a message. Once a message is sent, then the sender must wait for a reply before being allowed to send another message. One participant will be on the server side, while the other will be on the client side. |
| 16-8. | Full-Duplex Chat. Update your solution to the previous problem so that your chat service is now full-duplex, meaning that both parties can send and receive independently of each other. |
| 16-9. | Multi-User Full Duplex Chat. Further update your solution so that your chat service is multi-user. |
| 16-10. | Multi-User Multi-Room Full Duplex Chat. Now make your chat service multi-user and multi-room. |
| 16-11. | Web Client. Write a TCP client that connects to port 80 of your favorite Web site (remove the "http://" and any trailing info; use only the hostname). Once a connection has been established, send the HTTP command string "GET /\n" and write all the data that the server returns to a file. (The GET command retrieves a Web page, the "/" file indicates the file to get, and the "\n" sends the command to the server.) Examine the contents of the retrieved file. What is it? How can you check to make sure the data you received is correct? (Note: You may have to give one or two NEWLINEs after the command string. One usually works.) |
| |
| 16-12. | Sleep Server. Create a "sleep" server. A client will request to be "put to sleep" for a number of seconds. The server will issue the command on behalf of the client, then return a message to the client indicating success. The client should have slept or should have been idle for the exact time requested. This is a simple implementation of a "remote procedure call" where a client's request invokes commands on another machine across the network. |
| 16-13. | Name Server. Design and implement a name server. Such a server is responsible for maintaining a database of hostname-port number pairs, perhaps along with the string description of the service that the corresponding servers provide. Take one or more existing servers and have them "register" their service with your name server. (Note that these servers are, in this case, clients of the name server.) Every client that starts up has no idea where the server is that it is looking for. Also as clients of the name server, these clients should send a request to the name server indicating what type of service they are seeking. The name server, in reply, returns a hostname-port number pair to this client, which then connects to the appropriate server to process its request. Extra credit: Add caching to your name server for popular requests; Add logging capability to your name server, keeping track of which servers have registered and which services clients are requesting; Your name server should periodically "ping" the registered hosts at their respective port numbers to ensure that the service is indeed up. Repeated failures will cause a server to be delisted from the list of services.
You may implement real services for the servers that register for your name service, or just use dummy servers (which merely acknowledge a request). |
| 16-14. | Error Checking and Graceful Shutdown. All of our sample client/server code in this chapter is poor in terms of error-checking. We do not handle when users press ^C to exit out of a server or ^D to terminate client input, nor do we check other improper input to raw_input() or handle network errors. Because of this weakness, quite often we terminate an application without closing our sockets, potentially losing data. Choose a client/server pair of one of our examples, and add enough error-checking so that each application properly shuts down, i.e., closes network connections. |
| 16-15. | Asynchronicity and SocketServer. Take the example TCP server example and use either mix-in class to support an asynchronous server. To test your server, create and run multiple clients simultaneously and show output that your server is serving requests from both interleaved. |
| 16-16. | *Extending SocketServer Classes. In the SocketServer TCP server code, we had to change our client from the original base TCP client because the SocketServer class does not maintain the connection between requests. Subclass the TCPServer and StreamRequestHandler classes and rearchitect the server so that it maintains and uses a single connection for each client (not one per request). Integrate your solution for the previous problem with your solution to part (a) such that multiple clients are being serviced in parallel.
|
