<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">fedora 18<div>but netstat didnít say WAIT, it said ESTABLISHED</div><div><br></div><div><span style="font-family: Menlo-Regular; font-size: 12px;">tcp        0      0 135..249:46502   135..249:46502   ESTABLISHED</span></div><div><br><div><div>(eliding identical interior octets for privacy).</div><div><br></div><div>iím trying to understand your argument; are you saying this is a TCP hiccup?</div><div>it doesnít smell like that; especially as it never used to happen and now</div><div>it happens quite often.</div><div><br></div><div>On Nov 28, 2013, at 7:11 AM, Pieter Hintjens <<a href="mailto:ph@imatix.com">ph@imatix.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">What OS are you using?<br><br>I've seen this symptom before, where a server cannot re-bind to a TCP<br>socket when there is an old client connection still connected to the<br>defunct socket. If you run netstat -a you'll see the socket in a wait<br>state, forever. When the client disconnects and restarts, it all works<br>again.<br><br>The problem is not solvable afaik at the lower levels. The new server<br>cannot force the socket out of a wait state (SO_REUSADDR does<br>nothing), and the client does not (afaik) get an error on the socket.<br><br>One solution is to detect the error using heartbeats, and then<br>explicitly close the socket at the client side, which frees the<br>server-side port for new connections.<br><br>I do not recall seeing the problem on Linux, only on AIX and Windows,<br>which is why I wonder what OS you're using.<br><br>It would be nice to add the heartbeating into ZMTP and libzmq if we<br>had budget to do that (and if this is in fact the problem).<br><br>-Pieter<br><br>On Thu, Nov 28, 2013 at 3:42 PM, Andrew Hume <<a href="mailto:andrew@research.att.com">andrew@research.att.com</a>> wrote:<br><blockquote type="cite">a few months ago, i moved to czmq 3.2.3 and iíve been quite happy except for<br>one issue.<br>i notice this rarely, so iíve let it sit but now its become a nuisance.<br><br>i have a stats_server which binds a PULL on port 46502.<br>i have a hist_server which connects a PUSH to port 46502.<br>ordinarily, the stats_server stays up for ever, while every now and then,<br>we restart the hist_server process. so far, so good. and like always,<br>we can start these servers in either order and it all works.<br><br>what happens when we forget to restart the stats_server?<br>the hist_server runs happily, sending stats over the channel on 46502.<br>after (hours, days), we finally observe the stats_server is not up and we<br>start it. it now fails because port 46502 ďis in useĒ.<br><br>this seems to be a bug to me.<br><br>-----------------------<br>Andrew Hume<br>949-707-1964 (VO and best)<br>732-420-0907 (NJ)<br><a href="mailto:andrew@research.att.com">andrew@research.att.com</a><br><br><br><br><br>_______________________________________________<br>zeromq-dev mailing list<br>zeromq-dev@lists.zeromq.org<br>http://lists.zeromq.org/mailman/listinfo/zeromq-dev<br><br></blockquote>_______________________________________________<br>zeromq-dev mailing list<br><a href="mailto:zeromq-dev@lists.zeromq.org">zeromq-dev@lists.zeromq.org</a><br>http://lists.zeromq.org/mailman/listinfo/zeromq-dev<br><br></blockquote></div><br><div apple-content-edited="true">
<span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px;"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: 'Lucida Grande'; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;  "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: 'Lucida Grande'; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;  "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br>-----------------------<br>Andrew Hume<br>949-707-1964 (VO and best)<br>732-420-0907 (NJ)<br><a href="mailto:andrew@research.att.com">andrew@research.att.com</a><br><br><br></div></span></div></span></span>
</div>
<br></div></body></html>