Network Programming代写：CS168 Chat

Introduction

代写Python版的聊天应用，在Network Programming里面属于罕见的类型，通常这类作业都是C语言的。
不过Python版直接用socket包就好，也不需要像C语言一样处理大量的I/O异常，也算是比较省事的。

Chat

In this assignment, you’ll build a simple application that connects users over a network: a chat server. Similar to chat programs like Slack and IRC, your finished chat server will allow users to converse in different channels. Users can create and join channels; once a user is in a particular channel, all messages that she sends will be relayed to all other users in that channel.
This assignment (and the rest of the assignments in this class) should be implemented in Python 2. This assignment will introduce you to the socket programming API.

Resources

There’s a demo of the finished project available here.
If you have questions, first take a look at the FAQ section. If your question isn’t answered there, post to Piazza.
The Python Socket Programming HOWTO is a useful introduction to socket programming.
We’ve provided two files to help you test your code:
client_split_messages.py is intended to help you ensure your server is correctly buffering messages, and is described in more detail below.
simple_test.py tests a basic scenario where two clients communicate in a simple channel. simple_test.py represents only a small fraction of the points that we’ll test for when we grade your assignment, and is intended only to help you verify the basic format of your client’s output.

What are sockets?

A socket is an endpoint of a connection between two programs running across a network. Each socket is associated with a particular port number. Sockets are an abstraction provided by operating systems: programs create sockets, read from those sockets, and write to those sockets. When a program writes to a socket, the operating system sends data out a particular port; similarly, with the operating system receives data on a port, that data can be read from the socket corresponding to that port.
In Python, you can create a socket and connect to a remote endpoint by using the socket library as follows:

import socket
# The socket constructor accepts a few arguments; the defaults are fine for this class.
client_socket = socket.socket()
client_socket.connect(("1.2.3.4", 5678))
client_socket.sendall("Hello World")

The example above created a socket and connected it to port 5678 at IP address 1.2.3.4. Then, it sent a “Hello World” message to the server at 1.2.3.4:5678.
The example above created a client socket that was connected to exactly one remote endpoint. When you create a server, you’ll typically want to allow multiple remote clients to connect, and you don’t usually know the address of those clients when the socket is created. As a result, server sockets work differently:

server_socket = socket.socket()
server_socket.bind(("1.2.3.4", 5678))
server_socket.listen(5)

After creating the socket, rather than connecting to a particular remote destination, the code above bound the socket to a particular IP address and port, which essentially tells the operating system to associate the given IP address and port with the socket. Finally, the listen call listens for connections made to the socket. When a new client connects to the socket, the socket library will create a new socket to use to communicate with that client, so that the server socket can continue to be used to wait for inbound connections from other clients:

(new_socket, address) = server_socket.accept()

This call blocks until a client connects (using a connect() call, as in the example above), and then returns a newly created socket, new_socket, that can be used to send and receive data to and from the client. For example, the call

message = new_socket.recv(1024)

will block until there is data to receive from the client, and will return up to 1024 bytes of data.
You’ll need to do some reading to understand how all of these API calls work. In particular, be careful when using send and recv! send, for example, will not necessarily send all of the data passed into it. The Python Socket Programming HOWTO will likely be a useful resource.

Part 0 (to be completed in section)

The first part of the assignment will help you get started with the socket programming API and introduce you to basic client-server interaction. This part of the assignment will not be graded, and you’ll complete it.
For this part of the assignment, you’ll write a simple client and server. The client will send a single message from stdin to the server and then disconnect. The server should print messages it receives to stdout. If multiple clients connect to the server, the server should handle them sequentially (i.e., it should print the complete message from one client and close that connection before handling the next client).
The server should accept one command line argument, stating the port that the server should use:

$ python basic_server.py 12345

The client should accept two command line arguments: the hostname (or IP address) of the server to connect to, and the server port:

$ python basic_client.py localhost 12345

Your server should be reachable from any IP address associated with the machine (see the FAQ).

Blocking sockets

In this part of the assignment, it’s fine to use blocking sockets. “Blocking” means that a socket call may not return for a while, until the call completes. Cases when socket calls won’t complete immediately include:

• send: if the socket’s internal buffer is full so no data can be written
• recv: if the internal buffer is empty, so there’s no data to read (e.g., if the client has paused sending)
• accept: if these are no clients currently trying to connect

Example use

Here’s an example of how your client and server should work. Suppose two different clients connected sequentially:

$ python basic_client.py localhost 12345
I am a student in CS168. This class is awesome!
$ python basic_client.py localhost 12345
Why is Shenker so bad at drawing?

If a server had been started on port 12345 before the client was run, it should have printed output as follows:

$ python basic_server.py 12345
I am a student in CS168. This class is awesome!
Why is Shenker so bad at drawing?

Part 1

In the remainder of the assignment, you’ll build on your basic client and server to create a chat server with different channels that clients can communicate on. For a demo of how your server should behave, watch the video here.

Server Functionality

The server should accept a single command line argument that’s the port that the server should run on.
Unlike your server in part 0, your server in this part of the assignment must allow many clients to be connected and sending messages concurrently. Each client should have an associated name (so that other connected clients know who each message is from) and channel that they’re currently subscribed to. When a client first connects, it won’t have an associated name and channel. The first message that the server receives from the client should be used as the client’s name.
Future messages from the client to the server can take one of two forms. The first type of message is a control message; control messages always begin with “/“. There are three different control messages your server should handle from clients:

• /join [channel] should add the client to the given channel. Clients can only be in one channel at a time, so if the client is already in a channel, this command should remove the client from that channel. When a client is added to a channel, a message should be broadcasted to all existing members of the channel stating that the client has joined. Similarly, if the client left a channel, a message should be broadcasted stating that the client left.
• /create [channel] should create a new channel with the given name, and add the client to the given channel. As with the /join call, the client should be removed from any existing channels.
• /list should send a message back to the client with the names of all current channels, separated by newlines.

The second type of message is normal messages to the client’s current channel. All messages that are not preceeded by a / are considered normal messages. These messages should be broadcasted to all other clients in the channel, preceeded by the client’s name in brackets (see the example below). Messages should not be sent to client in different channels. If the client is not currently in a channel, the server should send an error message back to the client.

When a client disconnects, a message should be broadcasted to all members of the client’s channel saying that the client disconnected.
Sockets provide a data stream functionality, but they don’t delineate different messages. When a given recv call returns some data, the socket won’t tell you whether the data returned is a single message, or multiple messages, or part of one message. As a result, you’ll need a way to determine when a message ends. For this assignment, use fixed length messages that have 200 characters for all messages (including messages from the server to the client). If a message is shorter than 200 characters, you should pad the message with spaces (and the receiver should strip any spaces off of the end of the message). You can assume that no messages are longer than 200 characters.
Be sure that your code correctly handles the case where less than one message is available in the socket’s buffer (so a recv call returns fewer than 200 characters of data) and the case where more than one message is available in the socket’s buffer. You should handle partial messages by buffering: if a recv call returns only part of a message, your code should hold on to the part of the message until the remainder of the mesage is received, and then handle the complete message. For example, if a client receives 150 characters from the server, it should hold those 150 characters until 50 more characters are received. The client should only write the message to stdout once all 200 characters have been received. To help you check for your server’s handling of these cases, we’ve provided a special client (client_split_messages.py) that splits messages into many smaller messages before sending them to the server. This client only tests some of the scenarios your server should handle! You’ll likely want to modify this client to test for additional casess.

Error Handling

Your server should handle cases where the client sends an invalid message by returning an appropriate error message to the client. For example, if a client uses the /join command but doesn’t provide the name of a channel to join, the server should send back an error message. The provided utils.py includes format strings for all of the errors you should handle. You can use these format strings using Python’s string formatting operations. For example, utils.py defines the following error message:

CLIENT_SERVER_DISCONNECTED = "Server at {0}:{1} has disconnected"

You can use the .format function to replace the brackets with strings as follows:

error_message = CLIENT_SERVER_DISCONNECTED.format("localhost", 12345)

You are required to use the error messages defined in utils.py. If you do not use these error messages (with appropriate formatting), you will not get credit for error handling.
When commands lead to an error, the command should not cause any changes at the server. For example, if a client is currently in the cs168_tas channel and then tries to join a channel that doesn’t exist, the client should not be removed from the cs168_tas channel.
We will only test for errors that have associated error messages in utils.py in our testing. You’re welcome to check for additional errors if you’d like, but you will not be graded on them.

Client Functionality

Each client connects to a particular chat server, and is associated with a name. Your client should be started as follows:

$ python client.py Scott 127.0.0.1 55555

This command should connect to the server at the given address and port number, and then send a message with the name Scott.
After being started, the client should listen for messages from the server and from stdin. Messages from the server should be printed to the command line (after being stripped of any spaces at the end) and messages from stdin should be sent to the server (after being padded with spaces, as needed). The client should print [Me] to each new line, to make it clear which messages in the history were typed by the client. When the client gets a message from the server, it should write over the [Me] with the message from the server. For an example of this, take a look at the demo video linked above.
Here’s an example of a client’s interaction with a server that was started locally on port 55555:

python chatv3_client.py Panda localhost 55555
[Me] Hello world!
Not currently in any channel. Must join a channel before sending messages.
[Me] /list
[Me] /create 168_tas
[Me] /list
168_tas
[Me] Hello world!
Alice has joined
[Alice] Hi everyone! Does anyone know what we're doing on the first day of lecture?

After seeing Alice’s message, Panda stopped his client. After Panda created the 168_tas channel, a second client started:

python chatv3_client.py Alice 127.0.0.1 55555
[Me] /list
168_tas
[Me] /join 168_tas
[Me] Hi everyone! Does anyone know what we're doing on the first day of lecture?
Panda has left

Details

We’ve provided a utils.py file that has error messages that you should use. These are intended to make your life easier, and also to enable testing. Be sure you use these messages; otherwise, your code will fail the tests!

Non-blocking sockets

You’ll need to use non-blocking sockets for this part of the assignment, because both your client and server need to receive data from multiple sources, in an unknown order. Consider what would happen if your client used blocking sockets, as in part 0, with a call like:

message_from_server = client_socket.recv(200)

Now suppose that the server doesn’t send any messages for a while, but while the client is blocked waiting on the recv call to return, the user types some data into stdin. The client should read the data from stdin and send it to the server – but the client is stuck blocked waiting on data from the server socket! To address this problem, you can use non-blocking sockets.
To use non-blocking sockets, you’ll need to use the select call in the select library. For more about how to use select and a very relevant example, take a look at this page. While you are required to use non-blocking sockets for reading data and accepting connections, it’s fine to use blocking sockets for sending messages (since the messages you’re sending are short and you don’t need to handle sending a large number of messages in quick succession, send and sendall should not block for long periods of time).