Python Learning Journey Day21

The content of this section:

Project Combat: Develop a web chat room

Functional Requirements:

1. Users can chat with friends one-on-one
2. Can search, add someone as a friend
3. Users can search and add groups
4. Each group has an administrator can approve the user's Dabigatran request, the group administrator can use multiple, the group administrator can delete, add, Ban group friends
5. Can have a temporary conversation with people in the chat room (like QQ Group)
6. You can send pictures in a group
7. You can send files to your friends one-on-one

Knowledge Prerequisites:

1. Django
2. Html\css\js
3. Bootstrap
4. jquery, Ajax

Introduction to the future

First, we know that HTTP is a stateless, request/response mode of communication mode, that is, each time a user clicks through a browser page, you need to re-establish a connection with the Web server, and send their session ID to the server side to the server side to verify the identity of this user. To obtain data from a Web server, the client must proactively initiate a request and then receive server-side returns, and the server will not actively push messages to the client.

Based on the traditional Web server will only passively respond to the client request this knowledge, if we want to achieve the needs of Web real-time chat, basically there are several ways:

Polling (polling)

Polling (Polling) involves making a request from the client to the server to get some data, which is obviously a purely Ajax HTTP request. In order to get server-side events as quickly as possible, the polling interval (the time between two requests) must be as small as possible. But there is one drawback: if the interval is reduced, the client browser makes more requests, and many of these requests do not return any useful data, which in vain wastes bandwidth and processing resources.

Comet

Ajax with polling is very limited: it is not scalable and does not provide low latency traffic (as soon as the event arrives on the server side, they reach the browser at the fastest speed possible). Comet is a WEB application model in which requests are sent to the server side and maintain a long lifetime until a timeout or server-side event occurs. After the request is complete, another long-lived Ajax request is sent to wait for another server-side event.

One of the great advantages of Comet is that each client always has a communication link open to the server side. The server side can push events to the client by committing (completing) the response as soon as the event arrives, or it can even accumulate and then continue sending. Because requests remain open for long periods of time, the server side needs special features to handle all these long-lived requests.

There are two main ways to implement Comet:

Ajax-based long polling (long-polling) mode

The browser makes a XMLHttpRequest request, and after the server receives the request, it blocks the request until the data or timeout is returned, and the browser JS makes the request again after processing the request return information (timeout or valid data) and re-establishes the connection. During this time, the server may have new data arrived, the server will choose to save the data until the connection is re-established, the browser will retrieve all the data once.

Forever iframe (persistent iframe)

This technique involves a hidden Iframe tag placed on a page that points to a src servlet path that returns server-side events. Each time the event arrives, the servlet writes and refreshes a new script tag with JavaScript code inside it, and the contents of the IFRAME are appended to the script tag, and the contents of the tag are executed.

WebSocket

If the advent of Ajax is the inevitable development of the Internet, then the advent of comet technology is more revealing a helpless, just as a hack technology, because there is no better solution. Who should solve the problem of comet resolution is reasonable? Browser, HTML standard, or HTTP standard? Who should be the protagonist? Essentially, this involves data transfer, the HTTP protocol should be the first, it is time to change the lazy protocol of the request/Response mode.

The answer is given in the new generation of HTML standard HTML5, which provides a network technology WebSocket for full-duplex communication between browsers and servers. From the WebSocket draft, WebSocket is a completely new, independent protocol, based on the TCP protocol, which is compatible with the HTTP protocol and does not fit into the HTTP protocol, just as part of the HTML5. The script is then given another ability: to initiate a websocket request. We should be familiar with this approach, because Ajax is doing it, and the difference is that Ajax initiates HTTP requests.

Unlike the HTTP protocol's different request/response modes, WebSocket has a handshake (Opening handshake) process before the connection is established, and there is a handshake (Closing handshake) process before closing the connection. Once the connection is established, both sides can communicate in two directions.

Advantages and disadvantages of some of the above implementations

Polling: The client periodically sends an AJAX request to the server, returning the response information and closing the connection as soon as the server receives the request.
Pros: It's easier to write back-end programs.
Cons: Half of the requests are useless, wasting bandwidth and server resources.
Example: suitable for small applications.

Long Polling: The client sends an AJAX request to the server, the server receives the request and hold the connection until a new message returns the response information and closes the connection, and the client finishes processing the response and sends a new request to the server.
Advantages: In the absence of a message without frequent requests, the cost of small resources.
Cons: Server hold connections consume resources, return data order is not guaranteed, difficult to manage maintenance.
Example: WEBQQ, HI Web version, Facebook IM.

Long connection: embed a hidden iframe in the page, set the SRC attribute of the hidden IFRAME to a request for a long connection, or use a XHR request, and the server can continuously enter data to the client.
Advantage: The message arrives immediately, does not send the useless request, the management is also relatively convenient.
Disadvantage: The server maintains a long connection that increases overhead.
Example: Gmail Chat

Flash Socket: embed a flash program JavaScript using the socket class within the page to communicate with the server-side socket interface by invoking the socket interface provided by this flash program. JavaScript controls the display of the page after it receives information from the server side.
Pros: Realize real instant communication, not pseudo-instant.
Disadvantage: The client must have a Flash plugin installed, a non-HTTP protocol, and cannot automatically traverse the firewall.
Example: Network interactive game.

Python Learning Journey Day21