[erlang-questions] how: cascading events in gen_fsm
Lev Walkin
vlm@REDACTED
Tue Nov 27 23:52:53 CET 2007
Hate special cases...
Can you switch to a known-length-size-header processing after
dealing with a header?
From `erl -man inet`:
{packet, PacketType} (TCP/IP sockets):
Defines the type of packets to use for a socket. The fol-
lowing values are valid:
1 | 2 | 4:
Packets consist of a header specifying the number of
bytes in the packet, followed by that number of
bytes. The length of header can be one, two, or four
bytes; the order of the bytes is big-endian. Each
send operation will generate the header, and the
header will be stripped off on each receive opera-
tion.
jm wrote:
> The problem: I'm using gen_fsm to model a network protocol based on
> messages. For the most part the messages are <<runlength,
> message:runlength/binary>>, except for a few special cases in the
> initial handshake. The messages are sent over TCP, but there is no
> guarantee that a complete message or only one message will arrive in a
> packet. To get around this a queue is mantained as part of the state record,
>
> -record(state, {
> queue
> ....
> }).
>
>
> which is used to hold the bytes recieved but are yet to be processed.
> When there are bytes remaining after processing the current state the
> remainder is placed on the queue and
>
> gen_fsm:send_event(self(), {msg, <<>>}),
> {next_state, new_state, State#{queue = Remainder}}.
>
> is executed to cause the gen_fsm process to jump to the next state and
> continue processing. Two questions,
>
> 1) Can anyone see a problem doing it this way (race conditions, etc)?
> 2) Is there a better way to cascade states with gen_fsm?
>
>
> Jeff.
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
More information about the erlang-questions
mailing list