Re: snmptcl v. scotty

Juergen Schoenwaelder (schoenw@cs.utwente.nl)
Wed, 17 Jul 1996 18:48:29 +0200

John Stumbles <J.D.Stumbles@reading.ac.uk> wrote:

> I'm a newbie to SNMP, Tcl/tk, snmptcl and Scotty/tkined, and I'm confused
> and curious about the differences between the latter two.

> I've just got a copy of the Network Management Practicum ("Managing your
> network using SNMP" by McCloghrie and Rose) and one of the first things I
> noticed was that the book describes various public SNMP implementations
> including the TUDelft stuff (BTNG, Tricklet, Fergie & Gobbler), CMU SNMP,
> NOCOL, and snmptcl, but omits mention of the scotty/tkined stuff from
> TUBraunschweig. The book is (c) 1995 and I think Scotty/tkined has been
> around longer than that so I'm curious why there's no mention of it? (Is
> there some politics behind this?)

I guess this happened by accident. snmptcl and scotty were developed
without knowing about each other. See my little SNMP and Tcl history
(http://www.cs.tu-bs.de/ibr/projects/nm/scotty/tcl+snmp.html). There
is also a pointer to the Scotty package in the new edition of the
Simple Book and I am quite sure that there are no politics involved
this time. ;-)

> Anyhow my main queries are about how the two compare?

Both of them provide basically the same functionality at the SNMP API
level although the APIs differ in many details. The scotty package
provides additional APIs for sending ICMP packets, querying the DNS,
retrieving documents via HTTP etc. as well as an API to write SNMP
agents in Tcl. Both packages come with a set of scripts which are all
useful for different purposes.

> * Could I run both snmptcl and Scotty/tkined together?

Basically yes. Note however that the latest versions of both packages
are based on different Tcl/Tk versions. Note also that a snmptcl
script will not easily interact with e.g. the Tkined editor and that a
Scotty based script won't easily run under the snmptcl application
model. So don't expect them to work together. There might be some
coexistance problems (e.g. the way how traps/informs are received on
port 162 and forwarded to the management script) but these things are
not more different than what you experience if you are running
multiple commercial management applications on one host. And you have
the source of both packages so you can fix it. ;-)

Juergen