--- /dev/null
+---
+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
projects / thetarpit.git / commitdiff