[nanomsg] Re: More Go nanomsg updates
- From: Garrett D'Amore <garrett@xxxxxxxxxx>
- To: Gonzalo Diethelm <gonzalo.diethelm@xxxxxxxxx>, nanomsg@xxxxxxxxxxxxx
- Date: Mon, 14 Apr 2014 10:34:56 -0700
Actually it looks more doable than I thought:
https://github.com/natefinch/npipe/blob/master/npipe_windows.go
So its mostly a matter of importing this for windows. Very cool. :-) It
should be ~trivial to build a winipc plugin that provides this on Windows,
because Nate’s work provides the same API as Unix sockets on POSIX systems. I
might see if I can make this work on Windows later in the week. :-)
--
Garrett D'Amore
Sent with Airmail
On April 14, 2014 at 10:30:28 AM, Garrett D'Amore (garrett@xxxxxxxxxx) wrote:
On April 14, 2014 at 10:19:27 AM, Gonzalo Diethelm (gonzalo.diethelm@xxxxxxxxx)
wrote:
Garrett, what is the state of support in Go for IPC under Windows (ie Named
Pipes)? Could this be something easily added to gonano (to choose a specific
name)?
Go on Windows currently lacks an IPC layer (named pipes). If it were added to
Go, then it could be added easily to my implementation. It could also be
possible to add this using an external plugin/transport, as transports are
fairly pluggable in my implementation. But that would presumably mean writing
some native code for it. I’m not a Windows developer (I don’t even have tools
for developing on Windows), so I’m not the person to do it.
I could also “fake” IPC out by using a loopback (127.0.0.1) interface and a
custom port to rendezvous on path, which would allow programs written using
ipc/// strings to work. But really for those programs, it would be better to
just use tcp:// addresses.
I do wonder what advantages Named Pipes on Windows offer over using loopback
TCP connections.
Again, thanks for all your work, it is great for the project to have
alternative implementations.
Its been a real pleasure.. I’m looking forward to doing more with this stuff
soon.
- Garrett
On Mon, Apr 14, 2014 at 12:58 PM, Garrett D'Amore <garrett@xxxxxxxxxx> wrote:
More Go nanomsg updates: I’ve added the missing patterns, so right now the only
functionality that nanomsg has that my implementation is a common Device()
function, and a nanocat command line utility. I’ll be adding those soon. (And
then I’ll turn my attention to adding TLS to nanomsg itself, and probably
websocket to both nanomsg and my implementation.)
In addition, as before, it still supports the TLS transport, and a new STAR
pattern, which are unique to this implementation (not supported in nanomsg.)
(Martin, I’m using protocol number 100 for STAR, for now. We should probably
define a region of numbers for experimental protocols/patterns which might not
be considered “portable” between implementations in applications.)
As a little bonus, I did some more minor tuning, and my req/rep latency dropped
from 6458 ns/op to 5339 ns/op. That means that this implementation is now
about 20% *faster* than native nanomsg when using inproc. The other transports
got minor improvements, generally most benefiting the single threaded
(GOMAXPROCS=1), i.e. default configuration, run, yielding between 1 and 8 usec
(or about 15%-30%) improvement depending on the transport. This brings me
within spitting distance of nanomsg for TCP and IPC, although I think I’m still
paying some penalties for the extra distance from the native file descriptors
that Go forces me to pay. (For exmaple, IPC is still about 3 usec slower than
native nanomsg — 18.3 usec vs 15.7 usec for nanomsg.)
Sadly, when running multithreaded, we don’t see quite the same benefit for
latency, and throughput suffers about 2-3%. (When running single threaded, the
performance *improves* by about the same amount.)
There are also now options to configure timeouts, etc. and a “common” test
framework (which needs a lot more work to extend it.)
As usual, the code can be found here: https://bitbucket.org/gdamore/sp
--
Garrett D'Amore
Sent with Airmail
--
Gonzalo Diethelm
gonzalo.diethelm@xxxxxxxxx
Other related posts:
