Re: One last questions about daemons

K-mart Cashier wrote:
Maybe this is a bit vague...

What prevents the telnet or ssh daemon from consuming massive amounts
of cpu time? I mean, they both have to listen on a port constantly for
incoming connections. This means they have to do some type of polling,
right?

This is an interesting question.

The fact of the matter is, yes, something has to do this polling.
Something has to be listening at all times in case a packet with the
right MAC address, IP address, and port number comes across on the
wire. Otherwise it would go by without being noticed.

However, it's not the telnet or ssh daemon. It's not even the kernel.
Instead, that work has been moved all the way out to the network hardware.
There is dedicated hardware that listens on the wire all the time. When
it sees a packet with the right MAC address[1], it sends a hardware
interrupt to the processor. The processor, in turn, has dedicated hardware
that is constantly "listening" for interrupts. The processor will set
aside the normal stream of instructions being processed and start
the interrupt handler routine.

Once the interrupt is received, it is up to the operating system to do
something about it. The operating system has an interrupt handler which
responds to the interrupt for the packet. This is the first level at
which is there is not a part constantly checking for new activity. The
processor arranges to call the interrupt handler only when it's necessary.
From there the interrupt handler wakes up only the task that needs to
know, by checking a table (or other data structure) that maps ports
to threads.

On Unix, a process registers itself with the "I want to know about
packets on such and such port" data structure by calling a system call
like listen(). When a process calls listen(), the operating system
stops running the process's code. It takes the process out of the
queue of runnable processes and puts it into a queue of processes
that are waiting on some external event. The process will not use
any further CPU time until the external event happens. When the
external event happens (in this case, the receipt of a packet), the
interrupt handler will ultimately cause the process to be taken out
of the queue of waiting processes and put back into the queue of
runnable processes. The process will then see a return from the
listen() call.

So you're absolutely right that something is waiting all the time for
a packet. It's just that for efficiency reasons, modern operating
systems have extracted as much of that work as possible out of the
user software and put it into the hardware and the kernel. The
processor only (in theory) needs to monitor one interrupt line,
and that is sufficient for it to handle all external events. With
this arrangement, no software has to constantly poll anything.

- Logan

[1] or possibly on some simple network hardware, just when it sees
any packet at all.
.

Relevant Pages

  • Re: monitor UDP broadcast - once every 5 seconds
    ... >> I need to write an app that monitors a UDP broadcast stream. ... >> listen to a particular port once every 5 seconds and see if a packet ... >> want it to capture every packet. ... >> My problem is that once the TestPortListener starts listening, ...
    (comp.lang.java.help)
  • Re: One last questions about daemons
    ... Something has to be listening at all times in case a packet with the ... right MAC address, IP address, and port number comes across on the ... the interrupt handler routine. ...
    (comp.unix.programmer)
  • Re: off-topic ports 1720 and 6000-6009 shown even though they should be filtered
    ... PORT STATE SERVICE ... In any case the port is open, but nothing is listening. ... AFAIK you can't, because the source IP is that of the host which can't be reached, and most ISPs get unhappy if you SNAT the packet to appear to come from their router. ...
    (Fedora)
  • Re: monitor UDP broadcast - once every 5 seconds
    ... > I need to write an app that monitors a UDP broadcast stream. ... > want it to capture every packet. ... > My problem is that once the TestPortListener starts listening, ... > *all* packets for that port. ...
    (comp.lang.java.help)
  • Re: Best Plan of action for 2 forest.......
    ... PortQry reports the status of a port in one of the following ways: ... ..LISTENING This response indicates that a process is listening on the target ...
    (microsoft.public.windows.server.active_directory)