<br>i agree redesign the protocol.<br><br>memcached&#39;s memcache.c use SO_KEEPALIVE,SO_LINGER,TCP_<div id=":7z" class="ii gt">NODELAY,SO_REUSEADDR when open socket, push the closing event at the end of event queue when close socket.<br>
<br>i
think it&#39;s safe to let the client close the socket first, and server
only wait on an EOF event. so the &quot;ack&quot; means tell the client &quot;i&#39;m
closing&quot; in some way, maybe an EOF or write(&quot;shutdown&quot;)</div><br><br><div class="gmail_quote">On Sun, Aug 9, 2009 at 1:02 AM, Marc Lehmann <span dir="ltr">&lt;<a href="mailto:schmorp@schmorp.de">schmorp@schmorp.de</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">On Sat, Aug 08, 2009 at 05:54:25PM +0200, Graham Leggett &lt;<a href="mailto:minfrin@sharp.fm">minfrin@sharp.fm</a>&gt; wrote:<br>

&gt; &gt; Except that close does not cause data loss on a unix or windows system,<br>
&gt; &gt; no matter how often you repeat this untrue statement.<br>
&gt;<br>
&gt; Lots of people disagree:<br>
<br>
</div>You misinterpreted some documents before, and you continue to do so. And<br>
quoting me balatantly out of context is just evil. If you want help that<br>
way, look for another idiot, not me.<br>
<br>
Those people agree with me actually - maybe you need to learn reading the<br>
pages you paste, because so far, _all_ have supported what I said.<br>
<div class="im"><br>
&gt; <a href="http://blog.netherlabs.nl/articles/2009/01/18/the-ultimate-so_linger-page-or-why-is-my-tcp-not-reliable" target="_blank">http://blog.netherlabs.nl/articles/2009/01/18/the-ultimate-so_linger-page-or-why-is-my-tcp-not-reliable</a><br>

<br>
</div>This page basically says what I told you: the kernel will try, but there<br>
is no gaurantee. In fact, the page says it _usually_ works. It also says<br>
you need to use a proper protocol with ack. Whats your point? You are too<br>
stupid to read?<br>
<br>
(Note that shutdown for writing does not do lingering, but I already<br>
pointed that out).<br>
<div class="im"><br>
&gt; <a href="http://lists.freebsd.org/pipermail/freebsd-questions/2004-June/049093.html" target="_blank">http://lists.freebsd.org/pipermail/freebsd-questions/2004-June/049093.html</a><br>
<br>
</div>That says exactly what I said, too: the kernel will actually try to send<br>
the data in the background. The post complains that he doesn&#39;t get an<br>
error status from close() - true.<br>
<br>
The fix is to design your protocol properly, as I told you<br>
before. Problems reading?<br>
<div class="im"><br>
&gt; <a href="http://www.developerweb.net/forum/archive/index.php/t-2982.html" target="_blank">http://www.developerweb.net/forum/archive/index.php/t-2982.html</a><br>
<br>
</div>This basically tells you not to mess with the linger options, and<br>
certainly not to switch it off.<br>
<br>
While I didn&#39;t tell you that, I told you that the default behaviour is as<br>
safe as you can get it without ack.<br>
<div class="im"><br>
&gt; Feel free to Google further to see how confusing this issue is.<br>
<br>
</div>google completely agrees with me, and all the pages you gave so far as<br>
well.<br>
<br>
reality, too...<br>
<br>
Sadly, I don&#39;t know where your confusion comes from, but I find your<br>
insistence annoying: if you can&#39;t be bothered to carefully read what _I_<br>
wrote, and you can&#39;t be bothered to carefully read what _others_ wrote,<br>
then you cannot be helped.<br>
<br>
Your program is buggy, mine aren&#39;t. I tried to help you fix it, but you<br>
are not interested :(<br>
<div class="im"><br>
&gt; &gt; They do send an ack some way or another - HTTP/1.1 for example tells you<br>
&gt; &gt; how long the request or response is before sending it (or parts of it).<br>
&gt;<br>
&gt; I&#39;m not talking about the client reading from the server, I am talking<br>
&gt; about the server sending to the client.<br>
<br>
</div>In HTTP/1.1, servers do not close their side of the connection usually,<br>
clients do. In HTTP/1.0, this is indeed an issue.<br>
<br>
They did what for some reason you do not want to: they fixed their<br>
protocol.<br>
<br>
What do you buy by dragging me into pointless disucssions? Everybody<br>
except you agrees, you need to fix your protocol.<br>
<div class="im"><br>
&gt; The client does not send an ack back to the server saying &quot;I got it&quot;,<br>
&gt; that just isn&#39;t how HTTP works.<br>
<br>
</div>It closes the connection, therefore telling the server is has whatever it<br>
wants. I think I explained this before, and even gave you many examples.<br>
<br>
You can do this with shutdown or close. Or explciit acks. Or implicit<br>
acks.<br>
<div class="im"><br>
&gt; The server sends the last chunk, and if keepalives are not in effect,<br>
&gt; closes the connection. There is no ack received from the client by the<br>
&gt; server to say &quot;ack&quot;.<br>
<br>
</div>keepalives (are you talking about tcp?) have nothing to do with the issue,<br>
just as non-blocking or libev doesn&#39;t. if you mean http/1.1 keepalive<br>
(there is no such thing as &quot;http keepalives&quot;).<br>
<br>
note that keepalive this is a required part of http/1.1.<br>
<br>
I don&#39;t know what it gives you to continously introduce off-topic material<br>
here, keepalives, non-blocking and libev realyl do not have to do anything<br>
with this. you *need* to fix your protocol.<br>
<br>
that&#39;s how tcp/ip works. if you cnanot understand it, that&#39;s your problem,<br>
and if your program is buggy thats your problem too.<br>
<br>
annoying the very people who can help you is immensely stupid. congrats.<br>
<div class="im"><br>
&gt; What I am interested in knowing is how to achieve this in a non blocking<br>
&gt; fashion.<br>
<br>
</div>you have been told numerous times by me, with ample examples.<br>
<br>
instead of asking to clarify what you don&#39;t understand you just waste<br>
everybodies time by insisting the world works somehow diferently than it<br>
does, and ignoring the advice you got.<br>
<br>
please keep the list free for people who have actually have problems and<br>
are interested in solving them. all you need to solve your issue *has been<br>
written*.<br>
<br>
if you don&#39;t trust me, trust the pages you quote, they have valuable<br>
advice.<br>
<br>
if you have problems understanding tcp/ip, go to an appropriate forum, all<br>
this has nothing to do with libev, and I am frankly no longer interested<br>
in trying to help you anymore, it&#39;s simply pointless.<br>
<div><div></div><div class="h5"><br>
--<br>
                The choice of a       Deliantra, the free code+content MORPG<br>
      -----==-     _GNU_              <a href="http://www.deliantra.net" target="_blank">http://www.deliantra.net</a><br>
      ----==-- _       generation<br>
      ---==---(_)__  __ ____  __      Marc Lehmann<br>
      --==---/ / _ \/ // /\ \/ /      <a href="mailto:pcg@goof.com">pcg@goof.com</a><br>
      -=====/_/_//_/\_,_/ /_/\_\<br>
<br>
_______________________________________________<br>
libev mailing list<br>
<a href="mailto:libev@lists.schmorp.de">libev@lists.schmorp.de</a><br>
<a href="http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev" target="_blank">http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev</a><br>
</div></div></blockquote></div><br>