Surojit> Can someone please point me to a solution for beefing up
Surojit> straps to heelp prevent it from dropping traps in the even of
Surojit> a flood (1000+ traps at the rate of 25/sec).
Surojit> Anything tuneable, code changes are welcome...I've done minor
Surojit> things, but I'm hardly a socket guru. I do understand the
Surojit> workings of the strap code though.
Handling 25 traps / second should not be a real problem. Of course, it
depends to some extend on how many `client processes' are listening
for traps and how much processing they do as well as the overall
system load. Also, the UDP sockets do some queuing so that a short
burst should just fill the socket cache.
Anyway, there have been problems with straps due to some open sockets
inherited from the parent process. The attached patch agains 2.1.8
fixes this problem. (Thanks to Havard Eidnes for this patch.) I am not
sure if it helps to solve your problem, but the patch can't hurt.
Juergen
*** /tmp/scotty-2.1.8/tnm/snmp/straps.c Fri Sep 13 19:57:46 1996
--- straps.c Tue Mar 17 11:52:14 1998
***************
*** 126,131 ****
--- 126,145 ----
}
/*
+ * Close any "leftover" FDs from the parent. There is a relatively
+ * high probability that the parent will be scotty, and that the client
+ * side of the scotty-straps connection is among the open FDs. This
+ * is bad news if the parent scotty goes away, since this will eventually
+ * cause straps to "block against itself" in the "forward data to client"
+ * write() calls below, since straps itself is not consuming data from
+ * the client side of the leftover open socket.
+ */
+
+ for (i = 3; i < FD_SETSIZE; i++) {
+ (void) close(i);
+ }
+
+ /*
* Open and bind the normal trap socket:
*/
-- !! This message is brought to you via the `tkined & scotty' mailing list. !! Please do not reply to this message to unsubscribe. To subscribe or !! unsubscribe, send a mail message to <tkined-request@ibr.cs.tu-bs.de>. !! See http://wwwsnmp.cs.utwente.nl/~schoenw/scotty/ for more information.