Architectural overview
From MtdWiki
| Table of contents |
Threading Model
Generally, mt-daapd has at least 3 threads and two processes. The threads and processes are set up in main.c.
These threads are:
- Mainline thread: responsible for responding to shutdown requests and rescanning the database on the appropriate interval
- Signal Handling thread: responsible for catching signals and notifying the mainline thread about them
- Web server thread: listens for connections and spawns thread-handlers for each connection
The second process is the rendezvous/zeroconf/bonjour/wtf-ever process.
Mainline Process
- Reads the config file
- Starts the rendezvous process
- Opens the pidfile (as root)
- Daemonizes (if specified)
- Drops privs
- Masks signals and starts signal-handling thread
- Opens the database
- Performs a full scan of the mp3 directory
- Starts the webserver
- Registers rendezvous names
- Sits in a loop waiting for rescan interval to expire or a shutdown request to come in
Signal Handler Thread
- Sits in a sigwait(2) loop waiting for SIGTERM, SIGINT, and SIGHUP.
Basically, it passes these events to the main thread through global variables
Web Thread
- Sits in an accept(2) loop waiting for connections
Once these connections are established, they are dispatched to the appropriate handlers. For web requests (the admin web pages, for example), the connection is dispatched to config_handler in configfile.c. DAAP requests (/server-info, /databases/1/..., etc) get sent to daap_handler in dispatch.c.
Zeroconf Process
Basically, when setting up the zeroconf process, a pipe is opened, the process forked, and the rendezvous process listens for commands from the mainline server over the pipe. The second process is either the Apple mDNS POSIX daemon, howl, or the native Apple mDNS implementation. I chose to make it fork because I was unsure of the thread-safety of any of these implementations, so chose to isolate them from my process.
The API for the rendezvous module is specified in rend.h. It's a simple API, and doesn't necessitate a fork approach, so it doesn't necessarily preclude a Win32 native port.
I expect that before a 0.3.0 release, the Apple mDNS code will be removed in favor of dns_sd.h, dodging licensing problems, but making it harder for end-users.
