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.