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

[esr (Enzo Scossa-Romano)]

@RAc

control flow is driven by the clients

yes

@RAc

The solution IS strictly sequential from the point of view of a host communication transaction. You have not explained how your multiple ADCs map to host transactions. Does a client request a reponse from a specific ADC, or any ADC? If there is a 1:1 mapping, it is even more so strictly sequential.

Example:
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)

@RAc

However, if all client requests all come sequentially from the same peer (such as in the “polling” case), you would not need any multithreading at all, just a server that traverses an infinite “accept-read-write-close” loop, as you will never receive a new client request while you process the current one.

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

[RAc]

@esr

@RAc

However, if all client requests all come sequentially from the same peer (such as in the “polling” case), you would not need any multithreading at all, just a server that traverses an infinite “accept-read-write-close” loop, as you will never receive a new client request while you process the current one.

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”.

[esr (Enzo Scossa-Romano)]

@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?

[RAc]

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.

[esr (Enzo Scossa-Romano)]

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?

[RAc]

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.

[esr (Enzo Scossa-Romano)]

@RAc

the one to maintain your code is NOT as serial killer OR does not know your address

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

[esr (Enzo Scossa-Romano)]

@htibosch

@htibosch

I must admit that I have never heard of a “shutdown SHUT_WR (EOF) to notify server the request is complete”.

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.