View Source Barytherium.Network.Receiver (barytherium v0.6.2)
The Receiver
is designed to work with Barytherium.Network
to move frames from
an already opened socket, reporting status back to an instance of Barytherium.Network
,
and frames onwards to the parser. This is implemented as a loop with no message receiving
capabilities, outside of the reply made to a call to Barytherium.Network
to report the
CONNECTED frame, for which it receives back a tuple which sets out the heartbeats. The
loop ends on most error conditions, including those which can be created elsewhere (e.g.
if it gets {:error, :closed}
when calling recv).
Link to this section Summary
Link to this section Types
@type receiver_option() :: {:first_frame_timeout, pos_integer()} | {:heartbeat_receive_allowance, pos_integer()}
@type receiver_options() :: [receiver_option()]
@opaque state()
Link to this section Functions
Pulls data from socket and parses it for STOMP frames until there's an error condition.
Errors are casts to listener_pid
proxied via the corresponding Barytherium.Network
.
If an error is emitted, the socket is closed and the loop ends.
spec: {:barytherium, :disconnect, atom()}
Currently, you can expect :timeout, :closed, and :parse_error in the final position.
Note that :timeout from Receiver
expresses either a heartbeat timeout, or a pre-defined
timeout of 5000ms while waiting for the CONNECTED frame, there is currently no other
mechanism to specify receive timeout.
When the first frame (which must be a CONNECTED frame) is parsed, this comes back to
the Receiver, which calls the corresponding Barytherium.Network
with
{:connected_frame, frame}
. The reply to this message should be a tuple of two integers
which express the agreed heartbeats for sending and receiving, respectively.
Note that the parsing itself happens in the Parser
process, and parsing results originate
from that process.
Start the receiver loop as a linked task, see loop/1
.