-- 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