On 04/07/10 02:15, Kacheong Poon wrote:
On 04/ 2/10 06:53 PM, Alan Maguire wrote:
Sorry to be following up again, but I think it would
be helpful if I make a specific proposal wrt the
additional probes required, especially the tcp
close-related probes. I think adding the following
set of probes to the original proposal should hopefully
address shortcomings in this area in a manner
consistent with the connect-* and accept-* probes:
I'd recommend the project team not to add the following
probes. Firstly, they are quite confusing. For example,
I assume the intention of close-request is that an app
using socket does a close(). But note that TCP can send
a FIN when an app calls shutdown(SHUT_WR), which has
nothing to do with close(). And TCP does not have a
"shutdown request from a peer" mechanism. Secondly, the
probes seem to be tied to socket calls. But Solaris TCP
also supports TLI. It does not seem right to have API
specific probes in the TCP level. If the project team
wants to track API specific calls, I'd suggest that the
team adds sockfs or TLI level probes instead of having
them in TCP.
Yup, that's along the same lines as me asking whether
they should be introducing socket probes instead...
...
For UDP, as Darren suggests, it would be helpful
to have equivalents for the
accept-refused/connect-refused probes so that
users can detect cases where they attempt
to connect to nonexistent services. I think it
may make sense to stay away from
connect-refused/accept-refused for names as
these terms imply a connection, so I suggest
(the rather unwieldy):
udp:::port-unreachable-send
Fires when an ICMP port unreachable message
is sent in response to a UDP datagram heading
for a port with no UDP server. It is true that
an ICMP DTrace provider should cover this event,
but it might be helpful to have a probe point
within the UDP provider for such an event also.
udp:::port-unreachable-receive
Fires when an ICMP port unreachable message
is received in response to a UDP datagram.
I'd recommend the project team not to add the above
UDP probes. They are really "after the fact." For
example, the UDP end point can be already gone when
the ICMP message is received. As suggested by the
team, it is better to have an ICMP provider to catch
this kind of events. So I'd suggest that the team
only creates the send/receive probes in the UDP
provider.
Do you think that it might be useful to have a probe that
is triggered when an ICMP error packet arrives for an open
socket? (But not as an ICMP protocol probe.)
Darren
_______________________________________________
opensolaris-arc mailing list
[email protected]
