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

Kent Johnson kent_johnson at skillsoft.com
Wed Oct 27 05:14:26 CEST 2004 

At 10:51 PM 10/26/2004 -0400, Bill Mill wrote:
>Kent,
>
>I hope you don't mind if I respectfully disagree.

Not at all! A little friendly disagreement is good for us all!

>First off, the user
>explicitly stated that he would like to leave his interface options
>open, and this is more difficult to implement with threads.

Yes, I agree that a threaded solution doesn't address this requirement. But 
he will have to implement some kind of front end. Combining that front end 
with the sniffer in a single app could be an easy way to get started.

>Secondly, he would have to learn about threads and thread
>synchronization. While this is not overly difficult, it is more
>difficult than learning sockets (IMNSHO, more on this) and tends to
>lead to very subtle and difficult to debug errors.

I think there can be subtle errors either way. I don't think simple 
threaded applications are that hard but I've written a few already...you 
may have more experience with separate processes and socket interfaces.

>I believe that sockets would be simpler for him to use, and that he
>doesn't need all of the protocol worry that you mentioned earlier,
>because he can simply pass a fixed-length message from the controller
>to the network script. Reading the socket is very simple; if there is
>data, read X bytes. If not, keep on chugging.

I'm skeptical of this. But I admit I haven't written any applications this 
way. There will at least be buffering issues with the input - a complete 
command may not be available at once. It is possible that he will 
eventually want a threaded server anyway - one thread to listen for 
commands and another for the actual sniffer. In general I try to avoid 
inventing communications protocols from scratch. And Python xmlrpc is very 
easy to set up.

>Furthermore, once he's written the controller -> network script
>communication, he can experiment with his options *very* easily; text,
>GUI, web, whatever he wants.

Text and GUI would be simple; for a web interface he would then have to add 
a web server into the mix - running as yet another process? If a web 
interface is a real possibility I would start with a simple HTTP interface.

Kent


>Peace
>Bill Mill
>bill.mill at gmail.com
>
>
>On Tue, 26 Oct 2004 22:26:28 -0400, Kent Johnson
><kent_johnson at skillsoft.com> wrote:
> > 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
> >
> > _______________________________________________
> >
> >
> > Tutor maillist  -  Tutor at python.org
> > http://mail.python.org/mailman/listinfo/tutor
> >

More information about the Tutor mailing list