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