Calling close() on a non blocking socket from within an io watcher

[CodeAll]

i agree redesign the protocol.

memcached's memcache.c use SO_KEEPALIVE,SO_LINGER,TCP_NODELAY,SO_REUSEADDR
when open socket, push the closing event at the end of event queue when
close socket.

i think it's safe to let the client close the socket first, and server only
wait on an EOF event. so the "ack" means tell the client "i'm closing" in
some way, maybe an EOF or write("shutdown")


On Sun, Aug 9, 2009 at 1:02 AM, Marc Lehmann <schmorp at schmorp.de> wrote:

> On Sat, Aug 08, 2009 at 05:54:25PM +0200, Graham Leggett <minfrin at sharp.fm>
> wrote:
> > > Except that close does not cause data loss on a unix or windows system,
> > > no matter how often you repeat this untrue statement.
> >
> > Lots of people disagree:
>
> You misinterpreted some documents before, and you continue to do so. And
> quoting me balatantly out of context is just evil. If you want help that
> way, look for another idiot, not me.
>
> Those people agree with me actually - maybe you need to learn reading the
> pages you paste, because so far, _all_ have supported what I said.
>
> >
> http://blog.netherlabs.nl/articles/2009/01/18/the-ultimate-so_linger-page-or-why-is-my-tcp-not-reliable
>
> This page basically says what I told you: the kernel will try, but there
> is no gaurantee. In fact, the page says it _usually_ works. It also says
> you need to use a proper protocol with ack. Whats your point? You are too
> stupid to read?
>
> (Note that shutdown for writing does not do lingering, but I already
> pointed that out).
>
> >
> http://lists.freebsd.org/pipermail/freebsd-questions/2004-June/049093.html
>
> That says exactly what I said, too: the kernel will actually try to send
> the data in the background. The post complains that he doesn't get an
> error status from close() - true.
>
> The fix is to design your protocol properly, as I told you
> before. Problems reading?
>
> > http://www.developerweb.net/forum/archive/index.php/t-2982.html
>
> This basically tells you not to mess with the linger options, and
> certainly not to switch it off.
>
> While I didn't tell you that, I told you that the default behaviour is as
> safe as you can get it without ack.
>
> > Feel free to Google further to see how confusing this issue is.
>
> google completely agrees with me, and all the pages you gave so far as
> well.
>
> reality, too...
>
> Sadly, I don't know where your confusion comes from, but I find your
> insistence annoying: if you can't be bothered to carefully read what _I_
> wrote, and you can't be bothered to carefully read what _others_ wrote,
> then you cannot be helped.
>
> Your program is buggy, mine aren't. I tried to help you fix it, but you
> are not interested :(
>
> > > They do send an ack some way or another - HTTP/1.1 for example tells
> you
> > > how long the request or response is before sending it (or parts of it).
> >
> > I'm not talking about the client reading from the server, I am talking
> > about the server sending to the client.
>
> In HTTP/1.1, servers do not close their side of the connection usually,
> clients do. In HTTP/1.0, this is indeed an issue.
>
> They did what for some reason you do not want to: they fixed their
> protocol.
>
> What do you buy by dragging me into pointless disucssions? Everybody
> except you agrees, you need to fix your protocol.
>
> > The client does not send an ack back to the server saying "I got it",
> > that just isn't how HTTP works.
>
> It closes the connection, therefore telling the server is has whatever it
> wants. I think I explained this before, and even gave you many examples.
>
> You can do this with shutdown or close. Or explciit acks. Or implicit
> acks.
>
> > The server sends the last chunk, and if keepalives are not in effect,
> > closes the connection. There is no ack received from the client by the
> > server to say "ack".
>
> keepalives (are you talking about tcp?) have nothing to do with the issue,
> just as non-blocking or libev doesn't. if you mean http/1.1 keepalive
> (there is no such thing as "http keepalives").
>
> note that keepalive this is a required part of http/1.1.
>
> I don't know what it gives you to continously introduce off-topic material
> here, keepalives, non-blocking and libev realyl do not have to do anything
> with this. you *need* to fix your protocol.
>
> that's how tcp/ip works. if you cnanot understand it, that's your problem,
> and if your program is buggy thats your problem too.
>
> annoying the very people who can help you is immensely stupid. congrats.
>
> > What I am interested in knowing is how to achieve this in a non blocking
> > fashion.
>
> you have been told numerous times by me, with ample examples.
>
> instead of asking to clarify what you don't understand you just waste
> everybodies time by insisting the world works somehow diferently than it
> does, and ignoring the advice you got.
>
> please keep the list free for people who have actually have problems and
> are interested in solving them. all you need to solve your issue *has been
> written*.
>
> if you don't trust me, trust the pages you quote, they have valuable
> advice.
>
> if you have problems understanding tcp/ip, go to an appropriate forum, all
> this has nothing to do with libev, and I am frankly no longer interested
> in trying to help you anymore, it's simply pointless.
>
> --
>                The choice of a       Deliantra, the free code+content MORPG
>      -----==-     _GNU_              http://www.deliantra.net
>      ----==-- _       generation
>      ---==---(_)__  __ ____  __      Marc Lehmann
>      --==---/ / _ \/ // /\ \/ /      pcg at goof.com
>      -=====/_/_//_/\_,_/ /_/\_\
>
> _______________________________________________
> libev mailing list
> libev at lists.schmorp.de
> http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.schmorp.de/pipermail/libev/attachments/20090813/e16a6652/attachment.html>