Subject: Re: netstat and PIDs
To: der Mouse <mouse@Holo.Rodents.Montreal.QC.CA>
From: Darren Reed <firstname.lastname@example.org>
Date: 09/13/1996 11:12:48
In some email I received from der Mouse, sie wrote:
> >> I imagine the kernel must store this info somewhere since it has to
> >> deliver packets to said process - I guess via the descriptor
> >> table[s].
> > The kernel doesn't store this information, because it doesn't need it
> > during normal operation. The kernel doesn't deliver the packets to a
> > process. The packets get "delivered" to a socketbuffer which hangs
> > [off] the vnode. The first process to read from that vnode [gets]
> > the requested packets.
> Well, there does have to be _some_ link between the two, because a
> process that's blocked in a read or recvfrom on that socket will be
> awakened by arriving data. But that's probably not useful, because the
> only link between the two is (probably - I haven't specifically looked)
> a sleep/wakeup location pair, which if you wanted to take advatange of
> it would require walking the sleeping process chains. Probably easier
> to scan the open file tables.
If you want to associate pid's with network connections, why not use lsof
or similar ?
looking for the matching vnode pointer in the fd table is not what I'd
call an efficient approach to solving the problem.