forked from mirrors/kore
Remove included docs, they are outdated.
This commit is contained in:
Joris Vink
parent
6e4b403662
commit
ccd9e1046a
61
docs/MODULES
61
docs/MODULES
|
|
@ -1,61 +0,0 @@
|
|||
Page to function mapping
|
||||
========================
|
||||
In the configuration file you specify how pages on your site are
|
||||
mapped to what callback in your module.
|
||||
|
||||
static /profile.html serve_profile
|
||||
|
||||
The above example binds the callback serve_profile() to the profile.html page.
|
||||
Kore automatically calls this callback when the page is requested by a client.
|
||||
|
||||
All callbacks must be based on this prototype:
|
||||
int callback(struct http_request *);
|
||||
|
||||
Callback functions MUST return either KORE_RESULT_OK,
|
||||
KORE_RESULT_ERROR or KORE_RESULT_RETRY.
|
||||
|
||||
KORE_RESULT_OK will cleanup the request and remove it.
|
||||
KORE_RESULT_ERROR will disconnect the client immediately after returning.
|
||||
KORE_RESULT_RETRY will reschedule the callback to be called again.
|
||||
|
||||
Most of the times KORE_RESULT_ERROR or KORE_RESULT_OK should come from:
|
||||
int http_response(struct http_request *req,
|
||||
int status, u_int8_t *data, u_int32_t datalen);
|
||||
|
||||
The http_response() function is used to queue up the HTTP response
|
||||
(including status code and content to be sent).
|
||||
|
||||
If you wish to add headers to the response do so before calling http_response():
|
||||
void http_response_header_add(struct http_request *req,
|
||||
char *header, char *value);
|
||||
|
||||
If your callback wants to use POST data, it should populate it first by calling:
|
||||
int http_populate_arguments(struct http_request *req);
|
||||
|
||||
The returned value is the number of arguments available.
|
||||
After calling the populate function you can retrieve arguments by calling:
|
||||
int http_argument_lookup(struct http_request *req,
|
||||
const char *name, char **out);
|
||||
|
||||
This will store the value of the requested argument in the out parameter.
|
||||
If http_argument_lookup() returns KORE_RESULT_ERROR out will be NULL.
|
||||
|
||||
Please see the example/ folder for a good overview of a module.
|
||||
|
||||
Static content
|
||||
==============
|
||||
Static content is included directly in the module.
|
||||
The example module shows how this is done.
|
||||
|
||||
After adding each static component to the Makefile, it will convert it
|
||||
to a .c source file and export certain symbols that can be used by the module.
|
||||
|
||||
Each component gets 3 symbols:
|
||||
static_[html|css]_<component_name> actual data.
|
||||
static_len_[html|css]_<component_name> length of the data.
|
||||
static_mtime_[html|css]_<component_name> last modified timestamp.
|
||||
|
||||
API functions
|
||||
=============
|
||||
See includes/kore.h and includes/http.h for a definite overview.
|
||||
|
||||
11
docs/TODO
11
docs/TODO
|
|
@ -1,11 +0,0 @@
|
|||
Kore TODO list
|
||||
===============
|
||||
|
||||
- Websocket support.
|
||||
- Better param syntax
|
||||
- Auxiliary library framework.
|
||||
- Provide more API functions for generic stuff such as
|
||||
session handler, page building, etc etc.
|
||||
- API to programmatically configure, start and stop Kore.
|
||||
- Find that one memory leak that's causing me agony beyond belief.
|
||||
- Get my hands on a 48 core server to test stuff on.
|
||||
52
docs/scaling
52
docs/scaling
|
|
@ -1,52 +0,0 @@
|
|||
Scaling in Kore:
|
||||
- Badass mode
|
||||
- Minion mode
|
||||
|
||||
Badass mode:
|
||||
- Receives connections from browsers
|
||||
- Selects available remote minion worker
|
||||
- Ties connection to worker and acts as a proxy in between
|
||||
- Persistent connections between minion worker processes
|
||||
- Pushes module and configuration changes to minions
|
||||
|
||||
Starting Kore in badass mode, badass workers get <port>+<worker nr>:
|
||||
|
||||
# ./kore -b 127.0.0.1:3350 -c /etc/kore.conf
|
||||
|
||||
Minion mode:
|
||||
- ZERO configuration, minions get all required stuff from badass
|
||||
- Each worker connects to the main badass port announcing itself
|
||||
- Receives module
|
||||
- Receives page handlers
|
||||
- Receives ports for all badass workers
|
||||
- Connects to each worker, announcing itself
|
||||
|
||||
- Receives all HTTP requests, parses and handles them
|
||||
- Responses go back to badass
|
||||
- kore_log() and access_log() go to badass (one log location)
|
||||
|
||||
In badass mode, minions no longer need:
|
||||
- any configuration options.
|
||||
- CPU detection should happen via CLI or automatic
|
||||
Start a Kore process as a minion (and fetch everything from badass
|
||||
running on 127.0.0.1).
|
||||
|
||||
# ./kore -m 127.0.0.1:3350 (-c 8 cpu count)
|
||||
|
||||
Protocol between badass/minions:
|
||||
- Must be stream based (multiple different requests per single conn)
|
||||
- Badass assigns unique streamID per new external connection
|
||||
- The streamID is sent before each packet
|
||||
- Type is added as well:
|
||||
- 1 HTTP
|
||||
- 2 SPDY
|
||||
- 3 LOG
|
||||
- 4 ALOG
|
||||
- 5 MODUPDATE
|
||||
- 6 CONFIG
|
||||
- 7 PING
|
||||
- 8 FIN
|
||||
- Badass probably wants to buffer packets before sending them
|
||||
to the minion
|
||||
- Responses coming from minions are terminated by sending FIN.
|
||||
(at which point badass will start responding to client)
|
||||
Loading…
Reference in New Issue