Tcp transaction management: server send after client shutdown(SHUT_WR)


3 client requests all scheduled at the same time:

  1. ADC1 aquire for 10 sec
  2. ADC2 aquire for 5 sec
  3. ADC1 aquire on ADC value>5

request 1) and 3) are sequentially (put on same queue)
request 2) is concurrent to request1 (put on other queue)

see the example; explain me how to do this with request 1) and 2)

I believe I made it clear enough that this scenario only applies under the assumption of strictly sequential client requests.

Your use case is fairly straightforward to handle: In the middle state of the fsm outlined above (read request-gather results-write results), each worker thread knows which ADC is to be addressed and can thus put request relevant data on one of several queues (one queue per ADC, for example), passing identification data such as task id or a handle to a return queue, then blocks to wait for the corresponding ADC thread: Each ADC is being served by a thread that runs its own fsm, eg “remove request from its queue, serve request, pass result to the back queue passed in”.

1 Like

@RAc thank you for your time
is also a good option to use a task notify to say,for exmple, adc databuffer is ready to send?
instead of backqueue?

it depends on whether you need to pass data back to the worker task or not as task notifications have no payload. But since tbe workers need to send some kind of result from the adc upstream to the client, I would think that some payload would need to be passed back which implies q queue.

since on a single ADC there is no concurrent request i though to have a global struct containing the response, the worker know which ADC also at which global data to look.
Or is this bad idea and should avoid to use a global variable for this?

Do this only if you are absolutely sure that the one to maintain your code is NOT as serial killer OR does not know your address. Concurrency and global variables are natural enemies. Miss one transaction for whatever reason and your results go to the wrong worker. This is the kind of stuff that can cost you weeks of tedious debugging. When thinking concurrency, think encapsulation.

I am not A serial killer but i know my adress !
Thank you for the time, now i implemented everything in a single task 1 request at a time, and is much better to understand


Researching a little bit, as i understand, is SHUT_WR not a good way to indicate EOF and half open connections cause only problems.
So even if FreeRTOS is lacking this feature, no interest from my side.