<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Nov 29, 2015 at 3:25 PM, Frans Schneider <span dir="ltr"><<a href="mailto:schneider@xs4all.nl" target="_blank">schneider@xs4all.nl</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">But what about style? Would you consider a solution as you describe
    good style? I didn't see it in other projects used this way.</blockquote></div><br>With the caveats of Jachym in mind:</div><div class="gmail_extra"><br></div><div class="gmail_extra">As a stepping stone toward a more layered solution I think it is fine. You usually don't have speed concerns at that point and this somewhat splits the concerns up because you can move the unpacker to its own module. The primary problem is if you can't handle that other messages interleave with the packet processing. But I'm willing to say that this better be handled sooner or later since otherwise you can't move the packet processing out later. Say you always get packets A and B in the order [A, B] on the line. Then, because of TCP, you could get [A] and then [B] later on with a divide in between since the TCP stream got broken up that way. This argues that a message X *can* and *should* be able to interleave, in particular [A, X, B] is possible.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Usually processing follows a layered model where the lower layers are more syntax-oriented (i.e., is this even a protobuffed message?) and the higher layers encode semantics (can we receive this packet in that state?). A nice modular program can easily adapt this to different process models, as long as the layers are not intertwined too much. In the case of each session being a single TCP connection, and having perhaps thousands of these, I wouldn't worry too much about separating the decoder out to get more cores working. I'd probably just keep it inside a single process, but calling to a separate module, since you have ample concurrency in the project already. If, on the other hand, you are implementing uTP, where each message arrives on the same socket, then you should heed to words of Jachym and make the decoder loop as fast as possible and forward toward other workers on the inside, essentially setting off a core for decoding and demuxing.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Before looking for fast, it is often beneficial to look at correct: processes form nice isolation barriers. So if things start going wrong, what should die and how should it die? This can in certain situations drive you to a solution where it is better if the decoder is spawned in order to handle that part outside of the main semantic state. If the decoder goes wrong, then you are still keeping hold of your semantic state.<br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">J.</div>
</div></div>