The response of LIGHTTPD1.4.20 source Analysis Note State machine

In the Con_state_response_start state, the server begins preparing the RESPONSE for the client:

         CaseCon_state_response_start:/* * The decision is Done*-Create the Http-response-header * * */if(srv->srvconf.log_state_handling) {Log_error_write (SRV, __file__, __line__,"SDS","State for FD", CON->FD, Connection_get_state (con->state)); }if(-1= = Connection_handle_write_prepare (srv, con)) {Connection_Set_state (SRV, con, con_state_error); Break; } connection_Set_state (SRV, con, con_state_write); Break;

As you can see, this state primarily invokes the Connection_handle_write_prepare function, which sets the response headers (in fact, the value of "Content-length") based on the method the client requests.

Connection_handle_write_prepare function Execution Content:

1. The function first determines whether the connected mode is direct, if it is, the connection is not processed by the plug-in, is handled by the server itself.

2. Then determine the connection request method, if it is option, set the Allow value, and empty the write_queue, because no data needs to be returned. Setting Con->file_finished to 1 indicates that no files need to be sent to the client.

3. Compare the value of Http_status, if 204,205,304, stating that the server does not need to return a file to the client, only the headers in response and its previous section, and the setting con->file_finished to 1.

4. Determine the value of the file_finished. A value of 1 indicates that no file data needs to be returned to the client. For 1xx,204 and 304 states, set Content-length to a null value. If the method is head, then the server may need to return some data to set the corresponding content-length. If the value of file_finished is 0, set the value of Keep_alive.

5. Finally, call Http_response_write_header to write headers to Write_queue, waiting to be returned to the client. If all goes well, the state machine enters the Con_state_write state.

Here is the operation of the Con_state_write branch:

         Case Con_state_write:if(srv->srvconf.log_state_handling) {Log_error_write (SRV, __file__, __line__,"SDS","State for FD", CON->FD, Connection_get_state (con->state)); }/* Only try to writeifWe have somethinginchThe queue */if(!chunkqueue_is_empty (Con->write_queue)) {#if 0Log_error_write (SRV, __file__, __line__,"DSD", CON->FD,"Packets to write:", con->write_queue->used);#endif}if(!chunkqueue_is_empty (con->write_queue) && con->is_writable) {if(-1= = Connection_handle_write (srv, con)) {log_error_write (SRV, __file__, __line__,"DS", CON->FD,"Handle write failed."); Connection_set_state (SRV, con,Con_state_error); }Else if(Con->state = =Con_state_write) {con->write_request_ts = srv->cur_ts; }} break;

Since the data may not be written at one time, in the Con_state_write state, first determine whether the write_queue is empty, that is, there is no data to send. Also determine if the connection is writable. If there is data and can be written, call Connection_handle_write to send the data. If no data is writable or the connection is not writable, jump out of the switch (con->state) statement.

Since the state machine state is not changed, the IF statement behind the switch causes the server to exit the large while loop and enter the small switch (con->state) statement that follows the loop (if the state of the connection does not change, the connection read and write data is not finished, But wait for IO events). Here, enter the Con_state_write branch, if there is data writable and the connection is writable and does not reach the traffic limit, then register the connection in Fdevent, wait until the end of IO to continue to write data, otherwise, delete this connection.

When the data is writable and the connection is writable, go to the Connection_handle_write function and see the function:

1. First call the Network_write_chunkqueue function to write the data in the Write_queue back to the client. function Network_write_chunkqueue first to determine whether the current connection traffic exceeds the limit, if so, do not send any data, directly add the connection to the job list (joblist), so that the other connection to send data. If there is no overrun, set the Tcp_cork option first. This option can send multiple write calls together to improve the efficiency of the delivery.

2. Next Call the Srv->network_backend_wirte () function to actually write the data. There are multiple definitions of this function in the network_*.c file. The server sets different values in the Network_init function of NETWORK.C based on the current operating environment. The traditional Io method reads and then write, requiring 4 copies of data (from disk to kernel buffer, from kernel buffers to user buffers, from user buffers to kernel buffers of network interfaces, and finally from kernel buffers of network interfaces to network device buffers) to improve server efficiency. Different OS will provide some specific methods to reduce the number of copies (direct IO), to improve the speed of sending files, lighttpd according to different OS to invoke a specific interface to implement the Network_backend_wirte () function. These implementations are similar, taking the implementation in NETWORK_WRITE.C as an example:

The body of the function is a large loop that iterates through all the chunk.

If the type of CHUNK is Mem_chunk, then the data in this CHUNK is in memory, and the data is sent directly by calling write or the Send function under Windows.

If it is a file_chunk type, indicating that this chunk represents a file, then if the run environment has mmap function, the mmap map file is used and sent, otherwise read again write.

If the chunk is sent out, continue sending the next chunk.

If it is not finished (chunk_finished=0), exit the loop, and then exit the function.

3. The server returns to Network_write_chunkqueue, does some statistical work, and once again checks whether the traffic of the connection is overrun.

4. The last server is returned to Connection_handle_write.
If Network_write_chunkqueue returns-1, the server is faulted. The state machine enters the con_state_error.
If 2 is returned, the client closes the connection and the state machine enters Con_state_error.
Returning 0 indicates that the send is complete and enters the next state.
Returns 1 indicates that the data was not sent out, and the tag is_wirtable is 0.

5. After returning from the Connection_handler_write function, if the data is not sent, the state machine is still in the Con_state_write state, then the connection is added to the fdevent system, waiting for the next data to be sent. Repeat the process until the send is complete or an error occurs.

6. If the data is sent, the state machine enters the con_state_response_end state.

In the status con_state_response_end:

1. The server first calls Plugins_call_handle_request_done to notify all plug-in connections to finish.

2. Determine if the connection is maintained, and if so, set the state machine to Con_state_request_start. If not, call Plugins_call_handle_connection_close first to notify all plug-in connections to close, and then close the connection.

3. Reset con to clear the previous requested data.

　　
At this point, the request processing is complete.

The response of LIGHTTPD1.4.20 source Analysis Note State machine