# 2020q1 Homework4 (khttpd)
contributed by < `fwfly` >

## 整合 fibdriv 函式庫
為了不要讓 http_server 跟 fib 有太多的關聯性，所以只留一個 get_fib 給外面做呼叫。

## Content-Length
在實作發現就算加了結果到 response 也只會印出 hello world，原因是 Content-Length 沒有改變，而且 Content-Length 的長度要剛好等於結果的長度。如果太長 browser/curl 就會等待 (預期有更多內容)，太短則只會印部分的字串。所以在不光是 "hello world" 的字串要改，Content-Length 也需要一並更動。

## 字串串接
因為需要動態產生結果，所以需要串接字串．目前是使用 snprintf 然後接成一個 350 字元的字串, header 的部分佔約 170 剩下的部分約 39．
剩下的部分覺得拉大一點做保留。

snprintf(response_with_ans, 350, "%sContent-Length: %d\r\n\r\n%s\r\n",
                 hdr, len_fibres_int, fibres);

## 結果
在計算超過 134 時計算時間會到以秒計算。從之前的記錄可以知道在做 bigN to int 的時候會出現效能瓶頸
[BigN_to_Int 的效能問題](https://hackmd.io/KmJVxbH5S66a00zAP0wR4A?view#BigN_to_Int-%E7%9A%84%E6%95%88%E8%83%BD%E5%95%8F%E9%A1%8C)

$ curl http://172.20.10.2:8081/fib/100 354224848179261915075 
$ curl http://172.20.10.2:8081/fib/120 5358359254990966640871840
$ curl http://172.20.10.2:8081/fib/130 659034621587630041982498215

$ date
Wed 29 Apr 08:57:04 AEST 2020
$ curl http://172.20.10.2:8081/fib/134 4517090495650391871408712937
$ date
Wed 29 Apr 08:57:08 AEST 2020

## 效能測試實驗設計
因為知道在 134 之後會以秒計算，所以透過這樣的問題可以試看看如果大量的 request 都是在 130 以上時會發生什麼事情
然後透過 cmwq 看看能不能改善效能

## To do
* 支援數字到 $2^{31} - 1$
* 指出 kHTTPd 實作的缺失 (特別是安全疑慮) 並予以改正
* 引入 Concurrency Managed Workqueue (cmwq)
* 參照 in-kernel HTTP server，學習其中分析和實作手法，從而改進 kHTTPd