It's hard to catch these in code reviews because the typical approach is to mix the code that parses messages and the code the proceeds to the next state. For example you might have a parser that handles the first "Hello" message ...
-
Show this thread
-
before it even runs some piece of code is probably like "hey this is a hello message, call that parser!" and then at the end that parser will have a series of branches that are basically "hey, if I'm in this mode with X enabled, go here next, otherwise go there next".
1 reply 0 retweets 10 likesShow this thread -
When you're reading the code locally everything makes sense, because you're not thinking of other entry points or things being out of order. There's nothing glaring there.
1 reply 1 retweet 12 likesShow this thread -
One way to catch these errors is to use a protocol fuzzer; something that sends messages in random orders, tries to jam things up. But those are hard to write ... the messages need to be somewhat valid to get so far, and the combinatorial space to explore can be HUGE.
1 reply 0 retweets 28 likesShow this thread -
In s2n we do something differently. We borrow a trick first learned from S3's Doug Lawrence, combined with another trick from
@signalapp's@trevp__ .... we linearize the state machine into a static table, and we try to negotiate EVERYTHING just once. O.k. what does that mean ...1 reply 7 retweets 54 likesShow this thread -
O.k. so rather than having message parsers and generators that can transition states at all, we make them standalone, all they do is parse or generate messages. So how do we know which ones to call and when?
1 reply 1 retweet 18 likesShow this thread -
We put everything in a table, and use function pointers, see s2n's at:https://github.com/awslabs/s2n/blob/master/tls/s2n_handshake_io.c#L62 …
2 replies 0 retweets 39 likesShow this thread -
Replying to @colmmacc
So if I understand this correctly, this means you enumerate all possible states and all possible messages,. And that makes it easier to test because you can just go over them one by one. Is my understanding correct?
1 reply 0 retweets 0 likes -
Replying to @Jilyac
We enumerate of every valid order of states. Then, by choosing an enumeration just once, we reduce every state transition to a simple one step forward.
1 reply 0 retweets 0 likes -
Replying to @colmmacc
Ah I think I got it. With your code being structured this way, you ensure that there is a single "entry point" to each state and that it comes from a correct previous state?
1 reply 0 retweets 0 likes
Yep! I think of it like a single entry point into a strong "chain" of states. Rather than each state deciding where to go next ... which has been more likely to go wrong.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.