[nanomsg] more updates
- From: Garrett D'Amore <garrett@xxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Sun, 20 Apr 2014 15:00:38 -0700
I did some more work to SP for go. (Still haven’t renamed it yet, mostly
because I’ve not settled on a name.)
1. Device() now available. Turns out this is pretty trivial to do with
separate goroutines. I’ve included a test suite for it that demonstrates
routing across a three-device chain (TCP->TLS->Inproc loopback). (I still want
to write some better cocurrency and fanout tests for it — fanout especially for
pub/sub.)
2. In my implementation, I’ve decided to move away from “XSUB” vs. “SUB”, etc.
Instead, after you create the socket, you can put it into “RAW” mode
(SetOption(OptionRaw, true)). This allows Device to take any socket, not just
raw ones, and then put them into Raw mode. As part of this, I’ve done away
with the layered Raw vs. Cooked approach. I found that this layering added a
lot of extra code, for very little gain. The few places where behavior is
different are now just if () checks. The old behavior of binding to a raw
mode socket by using “X” version of the name is still supported for now. (When
we see an X name, if the underlying protocol doesn’t exist, then we try getting
the “base” protocol (without the X), and then setting the socket into raw
mode.) I would like to see that usage eradicated, but perhaps this model is
easier for nanomsg easiers to understand?
3. I’ve made a much more robust common test framework (the test code is about
41% of the code in the repo), and it includes deeper tests for each protocol,
including testing each protocol with each possible transport. It also includes
benchmarking of the TLS layer. (There is nothing to compare this with yet,
except base TCP. TLS roughly doubles the cost over pure TCP.)
4. The test framework has “automatic” handling of slow start, so that slow
start related failures should never occur. (Basically, we send sync packets
until we can verify that all listeners can hear from all senders, then we start
the actual test.) Btw, the test code — especially the device test code — may
be useful for folks wanting to understand how to use this stuff.
5. Fixed a possible use-after-free bug invovling the message headers with the
REP protocol.
As always:
https://bitbucket.org/gdamore/sp
I’d love to know if anyone is using this stuff. I know of one commercial user
(who are using it because I did the work for them :-) but as there are no
(other) known users, I’ve assumed I have a free hand to change things around.
--
Garrett D'Amore
Sent with Airmail
Other related posts:
