On Wed, May 10, 2006 at 09:55:49AM -0700, Erik Nordmark wrote: > Both RFC 4113 (UDP MIB) and RFC 4022 (TCP MIB) have a process ID for > each endpoint (udpEndpointProcess and tcpConnectionProcess). > > Was there any discussion how this can be implemented? Due to fork etc > there can be more than one process which has a socket open and only one > pid fits in the MIB. > > In addition, Solaris and BSD AFAIK doesn't let the socket layer track > the current (set of) processes that have the socket open - only the > first open (when the socket is created) and the last close results in > the socket layer being called. Thus the socket layer can only track the > process that can created the socket - a sequence of socket+fork+exit > would have that process go away but the socket remain open. > > Note that there are tools like lsof that allows showing the open files > for processes, including the TCP and UDP information for the file > descriptors that are socket. But that tool can handle a many-to-one > relationship from processes to sockets/endpoints, since it starts from > the process. > The MIBs attempt to do this from the endpoint/socket to the process, > which is what is problematic. > > Do we need to deprecate or clarify these objects?
While we can work out details such that these objects become implementable with a well defined semantic, I have the feeling that the result would not be terrible useful for management applications. The motivation for these objects was clearly to allow management applications to find the process(es) which deal with a given connection endpoint and as you write this can't really be achieved by adding more language to the DESCRIPTION clauses. So my preference would be to deprecate them since what we really would need is a n:m mapping table between process ids and transport endpoints. /js -- Juergen Schoenwaelder International University Bremen <http://www.eecs.iu-bremen.de/> P.O. Box 750 561, 28725 Bremen, Germany -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
