Erlang and OTP in Action.pdf - Synrc

278
User-Agent: curl/7.16.3 (powerpc-apple-darwin9.0) libcurl/7.16.3
OpenSSL/0.9.7l zlib/1.2.3
Host: localhost:1156
Accept: */*
The DELETE request is very similar to that of GET with the only major difference being
that in the initial request line the method is shown as DELETE instead of GET. The semantics
are quite different. With our GET request we asked for the resource referenced by /foo and
now we are asking to remove it. This examination of packets puts us in a good place. We
are now ready to move forward and actually implement our scaled down web server.
11.2.3 – Building the HTTP Server
Each request to the web server will be handled by a pair of processes. One will handle
the TCP socket and the other, the fsm, will handle parsing the HTTP protocol. When each
HTTP connection is made a simple one for one supervisor will spawn a gen_server called
ri_web_socket. That process will spawn and link with an FSM called ri_web_fsm. If one
goes down so does the other and the connection is automatically cleaned up for us. Figure
11.4 shows the process structure.
Figure 11.5
ri_sup
spawn_link
spawn_link
ri_web_socket
ri_web_fsm
The listen socket is created in the ri_app module and passed through the supervisor
structure into each of the spawned ri_web_socket servers so that is can accept incoming
connections on it. The design and interaction of the ri_sup and the ri_web_socket server in
terms of how connections are accepted is exactly the same is it was for ti_sup and ti_server
earlier on in this chapter. The only major difference here is the way that ti_server reads
data off of the socket. Instead of using {active, true} option we are using the active once
pattern. This is a very nice pattern because it offers the flow control you get with direct
©Manning Publications Co. Please post comments or corrections to the Author Online forum:
http://www.manning-sandbox.com/forum.jspaforumID=454