Hello, On 17 March 2017 at 10:03, Evgeny Grin <[email protected]> wrote: > Please note that even if you suspend connection, you must process at > least some data (preferably - all data) and decrement value of > 'upload_data_size'.
Yes, this was my mistake. Before suspending a connection I have to forgot about decrementing upload_data_size. I have questions: 1) Due the async nature of the MHD, how can I keep a connection in resume state _without_ reading data in DH? I mean, I can't say in which moment I can resume the connection with guarantee to read the data. I have to create some kind of queue with tracking which connection is could read data and which ones could not. And more importantly that I must guarantee that if I resumed a connection and it must read full data. Things getting complicated. Current DH logic looks like that: 1. I have to initialize internal structure per request, then it will be stored to con_cls and I return MHD_YES. 2. On the second entry into DH, I do process request: either upload a file, either suspend a connection. 3. When uploading the file has been finished I am resuming the next connection (if it is). 4. Even after resuming the connection there is a chance that a new connection will be proceeded before the "resumed" connection. I can track if the connection was resumed and give it a higher priority. But if so I have to suspend _all_ new connections before doing something useful. I will think about it, but, IMHO, it is wrong that I can't suspend/resume connections when I want without reading buffers. 2) Is it possible to do so that the chain suspend-resume-suspend-resume will not affect read buffers? Until I will "say" to MHD that I really read a data and we can continue in the normal mode. Because, by you words I can't resume a connection if I don't know will be it suspended again or not. I can resume the connection only if I give guarantees that it will be proceeded as usual (read all data). Thanks. -- With Best Regards, Vitaliy V. Tokarev
