From d3f665589608f15765ecc29506e45dd6aaa8415a Mon Sep 17 00:00:00 2001 From: Lucian Mogosanu Date: Tue, 16 Jul 2019 15:34:02 +0300 Subject: [PATCH] Add working draft for hunchentoot notes --- drafts/000-hunchentoot-ii.markdown | 79 ++++++++++++++++++++++++++++++++++++ 1 file changed, 79 insertions(+) create mode 100644 drafts/000-hunchentoot-ii.markdown diff --git a/drafts/000-hunchentoot-ii.markdown b/drafts/000-hunchentoot-ii.markdown new file mode 100644 index 0000000..b41633e --- /dev/null +++ b/drafts/000-hunchentoot-ii.markdown @@ -0,0 +1,79 @@ +--- +postid: 000 +title: Notes on Hunchentoot architecture +date: July 18, 2019 +author: Lucian Mogoșanu +tags: tech, tmsr +--- + +This post is part of a series on [Common Lisp WWWism][cl-www]. Before +continuing, I heartily recommend a review of [prior][cl-www] +[discussions][m7-work] on the subject. + +As [previously mentioned][hunchentoot-i], Hunchentoot is *big*, that +is, circa 6000-7000 LoC. However, despite its weight, our CL web +server of choice is not just an amorphous pile of code dropped from +the thought-prepuce of its original author; for one, it carries along +with it a well-written [documentation page][edicl-hunch] which +describes each of the pieces; and for the other, judging by the +technical documentation, we can at least hope that the code is to some +degree written by a sane mind. + +Thusly proceeding from these two artifacts (documentation and code), +the first step towards producing a genesis of Hunchentoot will be to +write down my own notes describing its organization -- I will point at +some coad, but I'm not diving into the functional details just yet; +instead, I am looking at the abstractions and the interaction between +components. + +First, some HTTP basics: let's say we have an ideal item H +representing a HTTP server. Our server H is a program that serves +pages to us; more concretely, it a. binds to a port P; b. waits for +incoming requests Rq on P; c. processes each Rq; and d. responds with +a reply Rp for each Rq. + +This model is all nice and dandy, isn't it? Except it doesn't lead us +anywhere by itself. The problem is that HTTP imports the notion of +"connection", and implicitly TCP, into its spec. This makes it very +inconvenient for us, because now H: a. binds to a (TCP) port P; +b. listens on P for incoming connections C; then c. each C needs to be +confirmed on H's end, i.e. it must be accepted by the server; then +d. for each C, H waits for one or more incoming Rqs; then it +e. processes each Rq; and finally, it f. responds with a Rp[^1]. In +addition to the increased complexity of this model, one other problem +is that the server has no way to tell when the requesting entity has +finished sending Rqs, so who's going to end C then? And either way, H +will now find itself in the position of having to manage Cs, which +have nothing to do whatsoever with the notion of a HTTP request. + +Now that we have the basics in place, let's take a look at the +abstractions exposed by our particular H, which for historical reasons +we've decided to christen Hunchentoot. + +[^1]: Quick likbez on how Unix and TCP make the whole thing work: + + In (a), the operating system allows H to take over P, i.e. it + keeps a note somewhere that H's user process takes some sort of + ownership over P. In (b), the listen system call is called, which + puts P's TCP socket into the "listening" state, as specced in [RFC + 793][rfc-793]. + + At this point, whenever a TCP client wants to initiate a + connection, it needs to go through the SYN-SYN+ACK-ACK three-way + handshake hula hoop; so the client sends his SYN, and then in + order for communication to move forward, the server must send his + SYN+ACK, which only happens in the accept phase, i.e. (c). Then + the accept function returns a socket for the new connection, and + only then can actual HTTP communication start. + + I won't even go into the details of why this is retarded, it's + been beaten to death in [the logs][tcp]. Either way, if the + Republic wants to keep speaking with the heathen world, we're + stuck using and possibly maintaining this pile of shit. + +[cl-www]: /posts/y05/090-tmsr-work-ii.html#selection-108.0-108.17 +[m7-work]: /posts/y05/094-tmsr-work-iii.html +[hunchentoot-i]: /posts/y05/093-hunchentoot-i.html +[edicl-hunch]: http://archive.is/MP2bT +[rfc-793]: http://archive.is/hFcq3 +[tcp]: http://btcbase.org/log-search?q=tcp -- 1.7.10.4