1: | Sockets. What is the difference between connection-oriented versus connectionless?
|
2: | Sockets. What is the difference between TCP and UDP?
|
3: | Sockets. Between TCP and UDP, which type of servers accept connections and hands them off to separate sockets for client communication?
|
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.
|
5: | Internetworking and Sockets. Implement Guido'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 "ls dir" and return dir's file listing |
You do not need a network to do this assignment—your 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!
|
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 which sends a dummy message over and wait for the reply. Once you have received a reply from the server, display it to the screen.
|
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.
|
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.
|
9: | Multi-User Full Duplex Chat. Further update your solution so that your chat service is multi-user.
|
10: | Multi-User Multi-Room Full Duplex Chat. Now make your chat service multi-user and multi-room.
|
11: | Web Client. Write a TCP client which 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 of the command string. One usually works.)
|
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 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.
|
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: (1) add caching to your name server for popular requests, (2) add logging capability to your name server, keeping track of which servers have registered and which services clients are requesting; (3) 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 which register for your name service, or just use dummy servers (which merely acknowledge a request)
|