Date: Wed, 24 Jul 2013 16:43:37 -0700 From: "Ronald F. Guilmette" <rfg@tristatelogic.com> To: Adrian Chadd <adrian@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: bin/176713: [patch] nc(1) closes network socket too soon Message-ID: <59915.1374709417@server1.tristatelogic.com> In-Reply-To: <CAJ-Vmo=OcMkqeo4AA9MdZwbhabu0uQV%2BEc_1qKt4AeLeWN3gqA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <CAJ-Vmo=OcMkqeo4AA9MdZwbhabu0uQV+Ec_1qKt4AeLeWN3gqA@mail.gmail.com> , you wrote: >Hi, > >Well, I've done this before. More than once. I'm glad that you've >stuck through helping me understand what nc is doing; I'm >unfortunately busy doing other things > >What you end up doing is: > >* tracking the state of the two sockets, both for read EOF and write EOF; >* whenever you get an EOF from one of the above four conditions, you >see whether you can still make progress. If so, you don't close the >socket - you just stop registering for that event. (Eg, if you see >read EOF on a socket, stop registering for read) >* if you see that both sides are read EOF'ed, then you can't possibly >make any more progress, right? >* .. no, you also have to THEN ensure that all the data you have >queued is written, OR that you hit write EOF (and thus can't make any >more progress anyway) > >_then_ you shut things down. > >Anyway. Leave it with me. Bug me if I don't commit either your fix, or >rearchitect it to do what I said above (and then test it, obviously :) Thank you. Please consider yourself bugged. (1/2 :-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?59915.1374709417>