[nanomsg] Re: more changes, TLS support added
- From: Vasiliy Tolstov <v.tolstov@xxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Tue, 25 Mar 2014 09:29:19 +0400
Please add udp support =)
2014-03-25 9:15 GMT+04:00 Garrett D'Amore <garrett@xxxxxxxxxx>:
> I’ve just made a rather substantial commit to my tree for the Go code.
>
> Recall the URI is here:
>
> https://bitbucket.org/gdamore/sp
>
> Here’s the commit:
>
> commit 0dcfb1955aa4969583bf1c085569b02985f54b57
> Author: Garrett D'Amore <garrett@xxxxxxxxxx>
> Date: Mon Mar 24 21:58:59 2014 -0700
>
> Fixes Issue 1: Add support for Pub/Sub
> Fixes Issue 7: Add (experimental) TLS transport
>
> Substantial work. It also cleans up a lot. Much that was formerly
> "Public"
> API is now "Private", making for much simpler documentation. There is
> suppo
> for SetConfig() and GetConfig() socket APIs, which allow configuration
> directives like TLS configuration to be passed to a socket.
> Also, we use this for PUB/SUB. We've also adopted some more idiomatic
> Go styles, and are using Factory methods to simplify dynamic handling
> of protocols or transports that need Init to be applied. (For example
> when
> these keep local state.)
>
>
> You can use addresses of the form "tls+tcp://lcoalhost:8001” in this code
> base. The TLS configuration is passed in using the standard Go TLS
> configuration struct, using a SetOption() command. This is validated using a
> self test, which can be used as an example as well. The code implementing
> *both* the server and client for REQ/REP over TLS is just under 300 lines,
> but almost 100 lines of that is in the form of embedded certificates and
> keys. (Which normally would come from a configuration file.) Most
> applications would just use stock configuration as well, which would further
> shrink the code.
>
> (Note that in my implementation, I use strings for option names, rather than
> integers. This allows me to avoid namespace collisions. The values of the
> strings are presented to developers as API constants. :-)
>
> I will probably write a self test for PUB/SUB, then I’ll call it a night.
>
> Expect the rest of the protocols to come together over the course of the next
> day or two. Frankly most of them are trivial compared to req/rep and
> pub/sub. :-) (That said, I’ve not looked too closely at the surveyor stuff
> yet.)
>
> - Garrett
>
>
--
Vasiliy Tolstov,
e-mail: v.tolstov@xxxxxxxxx
jabber: vase@xxxxxxxxx
Other related posts:
