Thank you Christian for the response. Thanks badari
On Wed, Nov 21, 2018 at 9:57 PM Christian Grothoff <[email protected]> wrote: > Dear Badari, > > Thanks for your surprisingly timely post. I just this week initiated an > off-list discussion with Evgeny about some odd corking/nodelay behavior > one of my students observed on OS X. So this is very much precisely on > my radar these days (but not yet a priority). > > Based on my discussion with Evgeny, the *desired* behavior should be > that MHD uncorks after (1) a large HTTP header *unless* the response > fits with the header in ~1200 bytes [Q: change behavior for 200 vs. > other status codes?], (2) at the end of the response, and (3) if the > application did send data and then calls suspend (without completing the > response). > > That said, this is not yet implemented correctly (suspend not at all, > the rest seems to be broken on some OSes and fine on others...), and > would need to be both documented / specified and tested. > > Help with this would be welcome, in the meantime all I can say is that > it is on our radar... > > Happy hacking! > > Christian > > On 11/21/18 4:37 PM, Badari Prasad wrote: > > Hi Christian, > > My application runs on fedora and is single threaded, for my testing > > application just receives the request and responds with 200OK with some > > json body (size <100 bytes )in the response. > > > > I did try running strace on MHD this is what I got. (client I am using > > libcurl application which sends 33k of body in http post with out Expect > > 100 header) > > > > 14:38:14.623432 epoll_wait(12, [{EPOLLIN|EPOLLOUT, {u32=21908544, > > u64=21908544}}], 128, 0) = 1 > > *14:38:14.623509 recvfrom(13, "POST /hello/TestMsg/async"..., 16384, 0, > > NULL, NULL) = 16384* > > 14:38:14.623825 rt_sigprocmask(SIG_UNBLOCK, [HUP QUIT PIPE ALRM TERM > > CHLD CONT TSTP TTIN TTOU WINCH IO PWR], NULL, 8) = 0 > > 14:38:14.623880 epoll_wait(5, [], 2, 50) = 0 > > 14:38:14.674038 rt_sigprocmask(SIG_BLOCK, [HUP QUIT PIPE ALRM TERM CHLD > > CONT TSTP TTIN TTOU WINCH IO PWR], NULL, 8) = 0 > > 14:38:14.674135 epoll_wait(12, [], 128, 0) = 0 > > *14:38:14.674175 recvfrom(13, "ey\": \"4\"\n},{\n \"key\": \"0\",\n > > "..., 15919, 0, NULL, NULL) = 15919* > > 14:38:14.674329 rt_sigprocmask(SIG_UNBLOCK, [HUP QUIT PIPE ALRM TERM > > CHLD CONT TSTP TTIN TTOU WINCH IO PWR], NULL, 8) = 0 > > 14:38:14.674375 epoll_wait(5, [], 2, 50) = 0 > > 14:38:14.724568 rt_sigprocmask(SIG_BLOCK, [HUP QUIT PIPE ALRM TERM CHLD > > CONT TSTP TTIN TTOU WINCH IO PWR], NULL, 8) = 0 > > 14:38:14.724666 epoll_wait(12, [], 128, 0) = 0 > > *14:38:14.724715 recvfrom(13, "key\": \"3\",\n \"key\": \"4\"\n},{\n > > "..., 15919, 0, NULL, NULL) = 1878* > > .... > > .... > > > > 14:38:14.743832 setsockopt(13, SOL_TCP, TCP_NODELAY, [0], 4) = 0 > > > > 14:38:14.743908 setsockopt(13, SOL_TCP, TCP_CORK, [1], 4) = 0 > > > > *14:38:14.743949 sendto(13, "HTTP/1.1 200 OK\r\nConnection: Kee"..., > > 162, MSG_NOSIGNAL, NULL, 0) = 162* > > > > 14:38:14.744022 setsockopt(13, SOL_TCP, TCP_CORK, [0], 4) = 0 > > > > 14:38:14.744189 setsockopt(13, SOL_TCP, TCP_NODELAY, [1], 4) = 0 > > > > 14:38:14.744234 setsockopt(13, SOL_TCP, TCP_NODELAY, [0], 4) = 0 > > > > 14:38:14.744286 setsockopt(13, SOL_TCP, TCP_CORK, [1], 4) = 0 > > > > Time diff I see is about 120 milli secs between MHD receiving request > > and sending response to the client. > > > > With this I got to understand that TCP_CORK and TCP_NODELAY is kind off > > delaying the response being sent out on transport layer... > > Is their a way to always enable TCP_NODELAY on MHD ? and check if we see > > this delay on transport layer ? > > > > Thanks in advance, > > Badari > > > > > > On Sat, Nov 10, 2018 at 11:53 PM Christian Grothoff <[email protected] > > <mailto:[email protected]>> wrote: > > > > On 11/9/18 5:44 PM, Badari Prasad wrote: > > > Hi, > > > I was going through old mailist archives, found one thread on > > > TCP_NODELAY > > > > > : > https://lists.gnu.org/archive/html/libmicrohttpd/2015-11/msg00077.html > > > But couldn't know if the option provided is it at compile time > flag or > > > runtime flag per connection basis. > > > > > > Kindly let me know the information on TCP_NODELAY option at MHD. > > > > Hi! > > > > To the best of my knowledge (i.e. unless there is a bug), TCP_NODELAY > > should be set/unset by MHD automatically whenever it makes sense to > do > > so. Your application doesn't need to do anything here. > > > > If you find/suspect that corking is inappropriately used, please > send a > > packet trace and maybe a bit of explanation as to how your code works > > (in particular, which platform you use and which threading mode is > > in use). > > > > Happy hacking! > > > > Christian > > > >
