SimpleTcpServer DataReceived method spawns a new task for each DataReceived event #161
Replies: 4 comments 3 replies
-
The client doesn't need to. It's managing exactly one TCP connection. The server manages many which is why a task is spawned for each. I did not want to implement my own scheduler so I left that to be the job of the underlying operating system. |
Beta Was this translation helpful? Give feedback.
-
But each server client connection already spawns a task to run its own data receiver. I don't see the benefit of then also spawning a task to handle the firing of the data received event. |
Beta Was this translation helpful? Give feedback.
-
Those events are fired synchronously. By burying them in a task it allows the server to fire more in parallel and get back to reading from the socket immediately. |
Beta Was this translation helpful? Give feedback.
-
It would nice to have the option to control this behaviour. In my use case I only have a single client connecting to the server at a time and high speed continous throughput is important. By having the read events firing from within tasks, this introduces the possibility of getting out of sequence data when reading as there is no guarantee as to which task will be scheduled next. |
Beta Was this translation helpful? Give feedback.
-
The implementation of the
DataReceiver
method in theSimpleTcpServer
spawns a new Task to call_events.HandeDataReceived
. this could potentially lead to problems as there is no guarantee that the tasks will run in the correct order (in high data rate scenarios). As each client runs theDataReceiver
as a separate task, I don't think it is necessary to do this (unless I'm missing something?)Interestingly, the
SimpleTcpClient
equivalent method does NOT spawn a new Task to call the_events.HandleDataReceived
method, which is inconsistent.Beta Was this translation helpful? Give feedback.
All reactions