workaround for intermittent failures of tcp_shutdown test on Windows

[TTimo]

This gross hack avoids the tcp_shutdown test failure on Windows. It also fixes an abort during shutdown that we encountered in our internal product while using the ipc transport (our internal bug had lower repro, but wasn't as pathological as the tcp_shutdown test - still, it was the same issue).

I'm not suggesting that this be merged, but I'm hoping someone can provide some insight as to what is going on (e.g. what is a non NN_SOCK_SRC_EP doing here) and point towards a better fix.

[djc]

Perhaps you should mention this on the mailing list, as well.

[JackDunaway]

@TTimo - I've likewise been working on this issue, and may have found a fix (linked below) -- perhaps you can give a try? Thanks!

https://github.com/wirebirdlabs/ftw-nanomsg/commit/bb5d37c70800aa620391c80a30b07dcc83501e26

[TTimo]

@wirebirdlabs the commit you linked doesn't apply cleanly against nanomsg master. It looks like some of your changes are already in master, whereas the change is otherwise built on older code. I was able to fix the merge conflicts correctly I believe, but tcp_shutdown still has the same failure pattern that I am working around in this pull request, in nn_sock_shutdown on

nn_assert (src == NN_SOCK_SRC_EP && type == NN_EP_STOPPED);

@wirebirdlabs your merged change against nanomsg master is at https://github.com/TTimo/nanomsg/tree/pull_303_internal_216_wirebirdlabs if you are interested in refining it.

@sustrik your input would be very welcome here. I am working to submit a few more pull requests, but they in part depend on this fix.

[JackDunaway]

@TTimo Great! I'll look into this. Right now, I'm neck-deep in fsm's and usock's getting full Autobahn Test Suite compliance on a new ws:// transport for nanomsg.

[djc]

@wirebirdlabs your ws:// transport sounds exciting, looking forward to it!

[TTimo]

I may have closed this one by mistake. It's still an issue / fix which we have in our prod code.

[JackDunaway]

This PR might effectively be handled by 7555f49 -- @TTimo , what do you think?

[gdamore]

Yep, I've resolved this a different way altogether. Closing this one.