Re: ECONNRESET not returned when calling send() on a socket

[Germain Le Chapelain <germain%lanvaux.fr@localhost>]

On Sun, 22 Dec 2019 09:41:53 +0000
Sad Clouds <cryintothebluesky%gmail.com@localhost> wrote:

> On Fri, 20 Dec 2019 15:23:41 -0800
> Germain Le Chapelain <germain%lanvaux.fr@localhost> wrote:
> 
> > On Sun, 22 Sep 2019 11:50:57 +0100
> > Sad Clouds <cryintothebluesky%gmail.com@localhost> wrote:
> > 
> > > I have a small client/server network application. Client opens a TCP
> > > connection to a server and starts writing data, at the same time
> > 
> > Why don't you just do that ?
> > Read and write on TCP
> > 
> > I have a feeling you are handling it from the "wrong end" by checking
> > yourself with poll().
> 
> What do you mean? I have no idea what you are suggesting here, i.e.
> there is nothing wrong with poll(),

I would :

 o use two threads on the server.  One for reading the other one for writting.
 o leave the sockets blocking
 o ignore sigpipe
 o treat any error in recv()/send() as a connection lost


I'm not saying poll() is wrong but it's more that from the other bits (different errors checking, sigpipe) , it felt to me like you are re-implementing TCP.

From what I gather TCP to be seen as a perfect stream, like pipes, for which the implementation is at the discretion of the os.
It almost felt like different versions of NetNSD had different behavior at connection loss, when checking at a lower level


I might be missing something I mostly dealt through OpenSSL, not directly through TCP. (BTW I never managed to get a client to gracefully close the connection from its end.)



-- 
Germain Le Chapelain <germain.lechapelain%lanvaux.fr@localhost>
Software Engineer
Lanvaux