Natter
Multiplexing comms over a single bidirectional channel is a useful ability. ZStreamMUX has proven itself, but to support fully bidirectional substreams it uses a pair of threads for each MUX instance, and another thread for each pending listener. For RPC-ish situations this is overkill.
Natter is a lovely English word that well describes a lightweight back and forth between participants. A
ZNatter
is constructed with a
ZStreamerR
and a
ZStreamerW
instance (often two aspects of a
ZStreamerRWCon instance).
From instantiation the two sides of a ZNatter are symmetrical, each sending and blocking till a response is received. Of course the interesting situations are the beginning and the end of such an exchange. On the server-ish side we call ZNatter::Receive. The result of such a call is a ZQ<ZData_Any>, with a ZRef<ZNatter::Exhange> as an optional output. On the client-ish side we can call ZNatter::Send and disregard any response, or we can instantiate a ZRef<ZNatter::Exchange> passing the ZNatter with which we wish to participate, and then call its SendReceive method.
It's certainly a constrained communication mechanism, but one that maps cleanly to common patterns with no extraneous resource implications.
From instantiation the two sides of a ZNatter are symmetrical, each sending and blocking till a response is received. Of course the interesting situations are the beginning and the end of such an exchange. On the server-ish side we call ZNatter::Receive. The result of such a call is a ZQ<ZData_Any>, with a ZRef<ZNatter::Exhange> as an optional output. On the client-ish side we can call ZNatter::Send and disregard any response, or we can instantiate a ZRef<ZNatter::Exchange> passing the ZNatter with which we wish to participate, and then call its SendReceive method.
It's certainly a constrained communication mechanism, but one that maps cleanly to common patterns with no extraneous resource implications.
