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
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 wrote:
> Hi Ch
Hi Christian,
I could get multiple streams working with suspend/resume. Took the
following approach:
1. When request is received, saved the stream id at application.
2. Suspend now would suspend only the stream logically, so the
connection is not suspended – no updating epoll fds as earl
Hi, It was fixed already in Git master by 1616caa17764c878bc18c6344a0f7f60b2cb596c -- Best Wishes,Evgeny Grin 28.12.2018, 09:08, "silvioprog" :Hello, I've tried to compile the latest stable version on MinGW-w64, but it raises the following error at build time (cut relevant parts only): wget --con
Thanks for answering dude! :-)
I'm going to test it ... 🏃
On Fri, Jan 4, 2019 at 5:56 PM Evgeny Grin wrote:
> Hi,
>
> It was fixed already in Git master by
> 1616caa17764c878bc18c6344a0f7f60b2cb596c
>
> --
> Best Wishes,
> Evgeny Grin
>
> 28.12.2018, 09:08, "silvioprog" :
>
> Hello,
>
> I've t
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 th
Hello dudes,
firstly, thanks Christian for indicating the MHD_fd* functions, I upgraded
my library to use them! :-)
Now I have a new challenge. I'm going to create two new examples for MHD
(issue #4914), however, I have a question. Is there any chance to use
zlib to compress data when creating a
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_W
Hi Christian,
We see that at the end of the load run, the connections at the TCP server
remain in CLOSE_WAIT state. We didn’t see this for single call. Also, I
wanted to tell you that all our connection are initiated from a single IP
as that is the load balancer IP and we are behind that.
We al
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 irr
On 1/5/19 5:51 AM, Santos Das wrote:
> Hi Christian,
>
>
> We see that at the end of the load run, the connections at the TCP
> server remain in CLOSE_WAIT state. We didn’t see this for single call.
> Also, I wanted to tell you that all our connection are initiated from a
> single IP as that is
11 matches
Mail list logo
