On Aug 27, 2011, at 1:51 PM, Alan D. Cabrera wrote:
>
> On Aug 26, 2011, at 7:35 PM, Emmanuel Lecharny wrote:
>
>> On 8/27/11 2:04 AM, Alan D. Cabrera wrote:
>>
>> simply because you can't move to the next filter unless you have transformed
>> what you've got from the previous filter. If we exclude all the utility
>> filters (like the loggers), a filter can only process a certain type of
>> message, and produce another type of message. The chain of filters is
>> dictated by the transformation done at each step. One good example is LDAP
>> processing : in order to decode a LDAP message, you first have to decode the
>> TLVs, then you can decode the messages themselves. A LDAP chain would be
>> something like :
>>
>> [outside filter] -> (bytes) -> { TLV decoder filter -> (TLVs) -> LDAP
>> decoder filter -> (LDAPmessages) } -> [outside filter]
>>
>> (add to this the fact that you may loop on the TLV filter *and* the LDAP
>> filter, plus the fact that you may have to wait for more bytes)
>>
>> Now, it makes *no sense* to exchange the filters. It will simply not work.
>> It's the very same for any protocol we will process with such a mechanism.
>>
>> In other words, the order the filters are executed is not random. It's fixed
>> by design, and does not change (as soon as we have ruled out the possibility
>> to have a dynamic chain).
>>
>>
>> Another way to see this mechanism is that it's a path from one point to
>> another : you may have many different paths, but for a set of bytes, you
>> will always follow the same path. The only way to follow two different paths
>> is when you get two different sets of bytes.
>
> I'm not sure that this needs to be a single FSM. Why not
>
> [outside filter] -> (bytes) -> [TLV decoder filter] -> (TLVs) -> [LDAP
> decoder filter] -> (LDAPmessages) -> [outside filter]
>
> I hear "looping" being a justification but it strikes me that using an FSM
> obfuscates things needlessly as I believe that a simple filter will do.
>
> Is there some code I can look at to see your above implementation? I think
> here is a perfect case for code bits to compare.
I took a bit of time to start fleshing out an LDAP server and now know why
we've been back and forth so often. You are using an FSM to parse messages and
I am using FSMs to implement network protocols. Two totally different things.
I think we should think about this for a bit but I will quickly state that I
think the way to handle this is to have something not unlike an SSL engine
inside a filter; look at my sloppy sketch that's "evolving" in my sandbox.
Regards,
Alan
