What is a daemon?
In computing, a daemon (pronounced DEE-muhn) is a program that runs continuously as a background process and wakes up to handle periodic service requests, which often come from remote processes. The daemon program is alerted to the request by the operating system (OS), and it either responds to the request itself or forwards the request to another program or process as appropriate.
Common daemon processes include print spoolers, email handlers and other programs that manage administrative tasks. Many Unix or Linux utility programs run as daemons. For example, on Linux, the Network Time Protocol (NTP) daemon is used to measure time differences between the clock on the computer it runs on and those of all other computers on the network. A time daemon runs on each of the host computers, with one being designated as primary and all others as secondary. Secondary daemons reset the network time on their host computer by first sending a request to the primary time daemon to find out the correct network time.
What role do daemons play in web services?
One of the most obvious examples of a daemon is the Hypertext Transfer Protocol daemon (HTTPd), which runs on every web server, continually waiting in dormant mode until requests come in from web clients and their users. Earlier versions of HTTP daemons would spawn a new process to handle each request. The new process, a replica of the daemon, would fetch the requested content and return it to the requesting client. Then, the new process would die.��By spawning a new process, the original process could go back to dormant mode to wait for other requests. This approach was used to prevent the original process from getting too busy to service new requests, as a daemon that handles all requests by itself would make a system more vulnerable to hackers. Denial-of-service attacks are often based on the strategy of keeping a daemon too busy to handle incoming requests
Connection Termination Protocol (Connection Release)
While it creates three segments to establish a connection, it takes four segments to terminate a connection. During a TCP connection is full-duplex (that is, data flows in each direction independently of the other direction), each direction should be shut down alone.
The termination procedure for each host is shown in the figure. The rule is that either end can share a FIN when it has finished sending data.
When a TCP receives a FIN, it should notify the application that the other end has terminated that data flow direction. The sending of a FIN is usually the result of the application issuing a close.
More modern HTTP daemons, such as Apache, handle requests using threads instead of spawning new processes. Threads, which came into common use well after the first generation of HTTP daemons were implemented and deployed, enable different parts of the same process to run in parallel. The main part of a daemon can wait for new requests, while other threads handle older requests. Threads require less overhead than spawning a new process, which takes time to accomplish, and the new process needs memory to run.
A third approach is exemplified by the Nginx HTTP daemon, which is based on an event-driven architecture operating in a single thread. Requests are handed off to worker processes, which constantly run in the background -- that is, they aren't spawned just to handle a request only to die off immediately afterward. The administrator determines how many worker processes to create.
What kind of operating systems do daemons require?
Since daemons require special services from the OS, they behave slightly differently from one operating system to another. The first daemons were run on the Unix OS and were designed around the features of Unix.
Daemons are started on the Unix command line or in a startup file; these files contain script that is executed when the system is booted or on some other event, such as user login or when a new shell script is spawned. They then run in the background and wait for a signal from the OS to wake up and go into action.
Daemons can only run on Multitasking OSes. They were implemented in Microsoft Windows, starting with the NT version, and are often referred to as Windows services instead of daemons.
What are examples of daemons?
Daemons respond to alerts from the OS upon some external event, such as the arrival of a message on the network. For messages coming from the network, the TCP/IP module on the host computer looks up the port number of the message and sends an alert to the daemon assigned to that port number. For example, port number 80 is assigned to HTTP, so when a message with that port number is received, the TCP/IP stack built into the OS sends a signal to the HTTPd.
Any system based on Unix or on a variant of Unix runs several daemons, the names of which typically end with the letter d. The following are some examples of daemons:
TCP Connection Establishment:
To make the transport services reliable, TCP hosts must establish a connection-oriented session with one another. Connection establishment is performed by using the three-way handshake mechanism. A three-way handshake synchronizes both ends of a network by enabling both sides to agree upon original sequence numbers.
This mechanism also provides that both sides are ready to transmit data and learn that the other side is available to communicate. This is essential so that packets are not shared or retransmitted during session establishment or after session termination. Each host randomly selects a sequence number used to track bytes within the stream it is sending and receiving.
The three-way han −
The requesting end (Host A) sends an SYN segment determining the server's port number that the client needs to connect to and its initial sequence number (x).
The server (Host B) acknowledges its own SYN segment, including the servers initial sequence number (y). The server also responds to the client SYN by accepting the sender's SYN plus one (X + 1).
An SYN consumes one sequence number. The client should acknowledge this SYN from the server by accepting the server's SEQ plus one (SEQ = x + 1, ACK = y + 1). This is how a TCP connection is settled
Connection Termination Protocol (Connection Release)
While it creates three segments to establish a connection, it takes four segments to terminate a connection. During a TCP connection is full-duplex (that is, data flows in each direction independently of the other direction), each direction should be shut down alone.
The termination procedure for each host is shown in the figure. The rule is that either end can share a FIN when it has finished sending data.
When a TCP receives a FIN, it should notify the application that the other end has terminated that data flow direction. The sending of a FIN is usually the result of the application issuing a close.
When a TCP receives a FIN, it should notify the application that the other end has terminated that data flow direction. The sending of a FIN is usually the result of the application issuing a close.
The receipt of a FIN only means that there will be no more data flowing in that direction. A TCP can send data after receiving a FIN. The end that first issues the close (example, send the first FIN) executes the active close. The other end (that receives this FIN) manages the passive close.