Thread: [Funk-devel] Queries and States in Funk - Design Review

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

 -- Good evening, please do not attempt to adjust your reader, there is
nothing wrong... --

I apologize for the delay, but I've been traveling and it was sunny outside.

My sun-eschewing colleague Elf has been hard at work, however...

He's completely refactored the raw-sockets egg, adding support for reading
as well as writing to packet sockets and non-blocking I/O!

This egg currently lives in src/eggs/rawsock, but will soon replace the
original raw-sockets.

Over the next few days, new code will be checked in, which will add support
for SIGIO and signal handling to the raw-sockets egg.

Once tested and working, this will complete the second phase of development.

This means that the ability to read and respond to network events is very
close at hand!

Thank you Elf!

----- Where do we go from here? -----

Phase 1 was writing, Phase 2 was reading... So next is Phase 3:

-- Query and Response - RFC --

We need a way of specifying certain packets that we want to respond to (a
'query') and then indicating what packets to generate and send as a
response.

Assume that the raw-sockets egg will handle the actual sending and receiving
of packets, and that incoming packets will all come through a single point
of control in the signal handler, a 'packet handler'.

We need to answer the following questions:

  1)  How does a user specify a Query?
  2)  How can the protocol definitions be modified to make Query matching
more efficient?
  3)  Should all Queries be compiled to allow to the packet handler to be
more efficient?  How?
  4)  What else needs to be added or changed in protocol definitions to
allow the decomposition of packets as well?
  5)  How can the user specify a set of state transitions at once?

I would like to provide an easy way of describing a state machine, where
transitions occur on incoming packets matching a Query and the states
correspond to generating traffic.

I'm thinking the sequence would go something like this:
  1)  User specifies a function that generates some packets.
  2)  User writes a query that calls this function when it matches certain
packets.
  3)  User starts the sniffer with his query, which triggers an implicit
compilation of queries.
  4)  When one of the interfaces the sniffer is attached to receives a
packet, it will invoke the packet handler.
  5)  The packet handler compares the compiled queries with the incoming
packet and generates some kind of event on a match.
  6)  This event will trigger a state change in the state machine, which
will transition to a new state, which is associated with the packet
generating function.
  7)  Packet generating function is called with input packet as argument,
GOTO STEP 4.

There are any number of problems with this, but I think this can be made to
work, and I believe the benefits to be insanely great.

So... What do you all think of this?  Do you have better ideas for this
design?

Do you have any idea of how to implement parts of this in Chicken?

I believe that the Query and Protocol definitions would be greatly
simplified with macros...  Any thoughts?

--- Other Thoughts ---

* We've opted not to use libpcap in any shape or form, although I'm still
planning to support PCAP capture and playback.

* I've been asked if there is any way to make sure that files are included,
and I don't know how to do this in a way that works in both compiled mode
and in the interpreter.  My current dirty hack is to write files that work
in the interpreter, and then separate files (ala. demo1.scm ) that are only
for compilation.  Does anyone have a better way of doing this in Chicken?

* Protocol Development Stalled - We're currently revisiting the format of
the protocol descriptions, to ensure that they will work with
Query/Response.  Until we have a better idea of if and how these formats
will be changed, we're not doing too much in the way of protocol
development.  That is left until Phase 4, loosely titled "Write a bunch of
protocols and demos".

Thanks to all of you for your input!

- Ben Kurtz

Thread: [Funk-devel] Queries and States in Funk - Design Review

funk-devel