Ah, sorry, I confused CLOSE_WAIT with TIME_WAIT. Hmm. You wrote that you set the timeout to 0, which means "disable". Maybe that is the issue?
On 1/5/19 5:34 AM, Santos Das wrote: > Hi Christian, > > We see that it never times out, i.e remain in CLOSE_WAIT state forever. > > Also, it is seen irrespective of whether we use loop back ip or a > regular eth0 IP. > > From my reading, I understand the following and we don't see that FIN is > received from Client but , we don't send FIN. > CLOSE_WAIT means that the local end of the connection has received a FIN > from the other end, but the OS is waiting for the program at the local > end to actually close its connection. > > > > On Sat, Jan 5, 2019 at 4:36 AM Christian Grothoff <groth...@gnunet.org > <mailto:groth...@gnunet.org>> wrote: > > Hi Santos, > > CLOSE_WAIT is a TCP state in the kernel after a TCP connection is > finished. It typically lasts like 60--300s, depending on your kernel > configuration (you may want to read up on the TCP state machine). > You can change the time by changing > /proc/sys/net/ipv4/tcp_fin_timeout, but usually this is not an issue > (unless you have _way_ too many TCP connections from the same host, I've > only seen this matter on loopback, in which case usually enabling > keep-alive on the client-side helps). > > Summary: this is not an issue in MHD, likely not one for anyone, just a > TCP artifact. > > Happy hacking! > > -Christian > > On 1/4/19 6:29 PM, Santos Das wrote: > > Hi Christian, > > > > Please note I am using suspend-resume and not > > implementing MHD_OPTION_NOTIFY_CONNECTION to close . Not sure when the > > library closes the connection after it receives FIN and move to > CLOSE_WAIT. > > > > Any pointers? > > > > thanks, santos > > > > On Fri, Jan 4, 2019 at 10:27 PM Santos Das <santos....@gmail.com > <mailto:santos....@gmail.com> > > <mailto:santos....@gmail.com <mailto:santos....@gmail.com>>> wrote: > > > > Hi Christian, > > > > Wishing you a happy new year! > > > > We have set the MHD_OPTION_CONNECTION_TIMEOUT to 0 and we see that > > all the connections remain in CLOSE_WAIT state. > > > > We also have set the MHD_OPTION_CONNECTION_LIMIT to 1000 . > > > > Any idea what could be wrong ? > > > > Thanks, Santos > > >
signature.asc
Description: OpenPGP digital signature