Re: Deleting a TCP connection in Mac OS X
Re: Deleting a TCP connection in Mac OS X
- Subject: Re: Deleting a TCP connection in Mac OS X
- From: Ryan McGann <email@hidden>
- Date: Thu, 05 Jun 2008 12:25:03 -0700
One thing that I have requested in the past, but not been
successful lobbying for, is KPI access to the PCB list in the
kernel. We _have_ to use the sysctl API sometimes because
maintaining our own PCB list by monitoring KPI events is not
practical, but some of the data in the pcb is quite useful. If
there were a way to access the PCB from the kernel and do our own
"translation" to private data structures, that would be much more
useful for us anyway, and probably yield better performance for our
users.
Allow me to add another request to this. I'd like to see an API
(and KPI) to kill a connection (delete a PCB). Open Transport
(Mentat/TCP) had this and users loved it (I still get requests for
this feature). Sometimes a connection gets wedged or misbehaves and
I have yet to find a simple way in Mac OS X to get rid of it (short
of restarting the whole stack).
...
I'd like to understand the kind of information people are looking
for in PCBs, so that perhaps they can be provided in future without
exposing the underlying implementation details. One issue related
to exposing the info in the PCB is locking; a lot of them are safe
to access/use when the proper lock is held. The issue with locking
is that they may change across releases.
Basically, the ability to map a port/pair to a socket. Or more
generally, the ability to determine if a port/protocol pair has *any*
socket associated with it, and what state that socket is in. Right
now, we have an entire kernel extension that does nothing except watch
for sflt_notify_* events to keep track of connected, bound, listening
and disconnecting sockets, so that when one of our other kernel
extensions receives an IP packet, it can lookup the state of the
protocol/port pair in our private hash. Adding a sflt_notify for bind
in Leopard helped (, but there's still quite a bit of jumping through
hoops which leads to duplicated code, memory and CPU cycles in the
kernel, just to find out something the kernel already knows
Unfortunately I won't be at WWDC this year, but I'd be happy to
discuss what we want in further detail off-line. We had a discussion
about this last year at WWDC, and I talked to Josh about it the year
before, so the Radar has been around for a while. But it's still
something I'd like to see improved in the future.
Ryan
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden