[erlang-questions] tcp data in a gen_fsm

[Jesper Louis Andersen]

On Sun, Nov 29, 2015 at 3:25 PM, Frans Schneider <schneider@REDACTED>
wrote:

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


With the caveats of Jachym in mind:

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.

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.

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.


-- 
J.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20151129/07475965/attachment.htm>