Hi, Thank you for your anwser Daniel.
I went for the multi_interface solution, coupled with a pause when there are no data to send and unpause when there are more data. I may have several connection (~1000), with a global throughput of 800Mb/s on a localhost endpoint Currently i call multi_perform when there are data to be sent. How can i obtain the send status ? By performing a select on the handles ? Here is what i am doing at the moment : if (bSomethingToDo) { // Call multi_perform curl_multi_perform(m_pstCurlMultiHandle, &iRunningFDs); } else { usleep(1000); } As i'm doing chunked encoding transfer, i don't have to check for a response on the handle but i'd like to know when packets could not be sent, and reinitiate the connection in that case (i have a init buffer to send at connection initialization) Regards, 2016-03-07 13:30 GMT+01:00 Daniel Stenberg <dan...@haxx.se>: > On Wed, 2 Mar 2016, Boutin Maël wrote: > > I'm currently using libcurl to send data over a nginx local server using >> HTTP POST and transfer-encoding chunked. >> >> My application is fed with buffers which i have to send as soon as i get >> them. These buffers may belong to various endpoints on the nginx server. >> >> My question is, what use of libcurl would you recommend for this task. I >> saw two options: >> > > Sure, both ways work and you can pretty much pick whichever you prefer. > > 1. Multiple threads >> I'd have one thread with a FIFO queue that would get the buffers and get a >> thread from a pool. This thread would then send the buffer to nginx >> > > I think it depends a little on how long period you expect to pass without > having any data to send. As libcurl will call the read callback when it is > ready to send data, you can basically just wait there until you get data, > but that might not be the nicest design if that can take a very long time. > > 2. One thread and multi interface >> I'd here work in non blocking mode with the multi interface. I'm not sure >> how i'd have to implement it and it seems quite overkill to me. >> > > You'd still have the same callback for that, but then you could return a > pause and you could have your select() wait for your own file handle > waiting for more data to arrive and then kick it back into running again > once data has arrived. > > * The connection with the server must not be closed even if there are no >> more data to send. >> > > Generic servers tend to not like too long pauses without data though. > > * If we cannot send data on the connection that it must be closed and >> reopened. >> > > That would imply a disconnect and libcurl will discover that and return an > error accordingly. > > -- > > / daniel.haxx.se > ------------------------------------------------------------------- > List admin: https://cool.haxx.se/list/listinfo/curl-library > Etiquette: https://curl.haxx.se/mail/etiquette.html > -- Maël BOUTIN
------------------------------------------------------------------- List admin: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html