Christian, > do whatever syscall you fancy to find out if the client disconnected. Do you mean something like recv(fd, buffer, sizeof(buffer), MSG_PEEK | MSG_DONTWAIT) and check for it to return 0? If so, once this returns 0 is it safe to assume that I can resume the connection and it will disconnect without invoking my access handler callback?
Thanks, Bob On Mon, Jul 29, 2019 at 12:08 PM Christian Grothoff <groth...@gnunet.org> wrote: > Hi Robert, > > You could grab the socket from the connection > (MHD_CONNECTION_INFO_CONNECTION_FD) and then do whatever syscall you > fancy to find out if the client disconnected. > > However, note that there may not be a reliable way to do this, because > without a TCP FIN/CLOSE/RST from the client, the server may simply never > notice that the client is gone until it tries to send data to the client > and that then causes a RST. This limitation also applies to the > resume/suspend approach you mapped, and fundamentally arises from the > design of TCP. > > Manually setting socket options to demand TCP KEEPALIVE from the OS > should theoretically mitigate this, I don't know about the practical > implications though (= have not tried). > > Happy hacking! > > Christian > > On 7/29/19 5:08 PM, Robert D Kocisko wrote: > > Hello all, > > > > Context: Single thread, external select with epoll. > > > > I have been using the suspend/resume flow control mechanism of > > libmicrohttpd to implement longpoll functionality, but now have a new > > use case where it is important to be able to check a particular > > connection while it is suspended to know whether the client has > > disconnected. The only way I can imagine doing this is to resume the > > connection for some amount of time (how long?) and see whether the > > MHD_OPTION_NOTIFY_COMPLETED callback gets called and then suspend the > > connection again. But I'm wondering if there's a simpler way to do this > > that doesn't involve resuming and waiting for a callback? > > > > Thanks, > > Bob > >
