[Tutor] Turning a "script" into an "application"

Kent Johnson kent_johnson at skillsoft.com
Wed Oct 27 04:26:28 CEST 2004


Christian,

If you want to be able to control your sniffer from a variety of front ends 
(command-line, GUI, web app) then you probably have to write it as a 
separate process with some kind of socket interface. If you can pick a 
single UI, and you are happy to have the UI running at the same time as the 
sniffer, you could make the sniffer a separate thread in the same 
application as the GUI.

Putting the GUI and the sniffer in one application is simpler. You don't 
have to invent a socket communications protocol, you can use program 
variables to communicate between the two threads (GUI and sniffer). You 
could write the GUI in Tkinter or wxPython.

If you decide to build a separate sniffer process, I suggest you build the 
communications protocol on top of an existing standard. That way you can 
use existing libraries to build the infrastructure. Inventing and 
implementing a socket protocol from scratch is probably not what you want 
to spend your time on.

For example you could use XMLRPC to talk to the sniffer. Using xmlrpclib on 
the client side and SimpleXMLRPCServer on the sniffer side it is easy to 
set up. The client then makes procedure calls on the server through a 
proxy. The advantage of this method is it is easy to set up and it gives 
you a very pythonic interface on the client side. The disadvantage is that 
it is not easy to use the interface without writing a program.

Another way to go is to use HTTP as your protocol. In this case you put 
request parameters in the URL. The server decodes the request and takes the 
appropriate action. An advantage of this method is you can test it with a 
browser client - by typing URLs or filling out a simple form you can 
control the sniffer. You could develop that into a rich web interface. I 
think you have to go outside the standard library to get good HTTP server 
support. There are many packages available; Snakelets is one that is 
intended to be easy to use: http://snakelets.sourceforge.net/

I suggest you start with the first version - GUI and sniffer in one 
application. It is a good first step even if the eventual goal is to have a 
separate sniffer process. Keep a strong separation between the two parts so 
if you decide later to split them it won't be too hard.

Kent

At 05:27 PM 10/26/2004 -0500, Christian Wyglendowski wrote:
> > -----Original Message-----
> > From: Bill Mill [mailto:bill.mill at gmail.com]
> > Subject: Re: [Tutor] Turning a "script" into an "application"
> >
> > Christian,
> >
> > I'm not really sure what you're asking. Do you have more
> > concrete questions?
>
>My main question boils down to: what programming/conceptual framework I
>should use to turn my script into something resembling an application?
>
>I guess maybe I was a bit vague in my description.  First off, the
>program watches the network for virus-like patterns of behavior, and
>alerts a user via email if it sees it during its capture window.
>
>Here is the basic flow I would like to see in the program:
>
>#RUNNING CONTROLLER
>|--> user can change options (captureTime, warnThreshhold,
>networkDevice, sleepTime, notifyAddress)
>|--> user can start/stop sniffer
>|--> user can save capture analysis
>|
>|_____ #RUNNING SNIFFER (basically a loop)
>         |--> sniffer runs for captureTime seconds
>         |--> sniffer analyzes captured data
>         |--> sniffer saves analysis to memory
>         |--> depending on analysis, sniffer sends alert via email or
>does nothing
>         |--> sniffer sleeps for sleepTime, then loops
>
>Sorry for the bad ASCII diagram - but hopefully it makes some sense.
>
> > It seems to me that, instead of messing around with threads,
> > you may want to write an entirely seperate script to control
> > the network script. Pseudocode:
> >
> > ##############
> > #network_script_controller
> > #############
> > while 1:
> >     actions = {'1': send_foo_to_network_script,    #this is a function
>reference
> >         '2': send_bar_to_network_script                 #so is this
> >         #and whatever else menu options you want
> >         }
> >     print "Enter one to change foo, or two to change bar"
> >     msg = raw_input('>')
> >     actions[msg]()
> >
> > #############
> > #network_script
> > ############
> > while 1:
> >     do_my_processing_loop()
> >     check_for_new_messages()
> >
> > And you could simply use sockets for communication between
> > the two. Is that something like what you're looking for?
>
>Thanks for the idea.  Despite not reall knowing what I was asking, you
>answered my question pretty well!  I had not considered a multi-process
>approach but I can see that it could be quite flexible.
>
> > Peace
> > Bill Mill
> > bill.mill at gmail.com
> >
>
>Thanks again.
>
>Christian
>http://www.dowski.com
>
>_______________________________________________
>Tutor maillist  -  Tutor at python.org
>http://mail.python.org/mailman/listinfo/tutor



More information about the Tutor mailing list