Блог

На одном компьютере запущены клиентское и серверное приложения. Они используют асинхронную связь с TcpClient и TcpListener.

Серверное приложение выполняет некоторую обработку данных в фоновом рабочем потоке. Каждый раз, когда обрабатывается каждая часть данных, он пытается отправить ее с помощью TcpListener, если к нему подключен какой-либо клиент и отправил запрос на получение обработанной части данных.

Сразу после вызова функции BeginWrite сервер устанавливает флаг клиента, чтобы избежать отправки новых данных, пока клиент не отправит другой запрос. Когда запрос поступает в TcpClientDataReadAsyncCallback(), для клиента устанавливается флаг, чтобы фоновый рабочий мог отправлять данные этому клиенту

Вот журнал сервера и клиента

 server

00.37.35.772 127.0.0.1:6012 recv 257 bytes of client Request 634538758557701309
00.37.35.860 127.0.0.1:6012 sent 175652 bytes to client
00.37.35.892 127.0.0.1:6012 recv 257 bytes of client Request 634538758558675330
00.37.35.952 127.0.0.1:6012 sent 188927 bytes to client
00.37.35.983 127.0.0.1:6012 recv 257 bytes of client Request 634538758559585382
00.37.36.052 127.0.0.1:6012 sent 174790 bytes to client
00.37.36.083 127.0.0.1:6012 recv 257 bytes of client Request 634538758560595440
00.37.36.153 127.0.0.1:6012 sent 188491 bytes to client
00.37.36.187 127.0.0.1:6012 recv 257 bytes of client Request 634538758561605498
00.37.36.249 127.0.0.1:6012 sent 178723 bytes to client
00.37.36.280 127.0.0.1:6012 recv 257 bytes of client Request 634538758562491540
00.37.36.373 127.0.0.1:6012 recv 257 bytes of client Request 634538758563739542
00.37.36.436 127.0.0.1:6012 sent 191229 bytes to client

client

00.37.35.864 127.0.0.1:6012 recv 175652 bytes of server Response 634538758558455318
00.37.35.867 127.0.0.1:6012 sent 257 bytes Request to server 634538758558675330
00.37.35.957 127.0.0.1:6012 recv 188927 bytes of server Response 634538758559455375
00.37.35.959 127.0.0.1:6012 sent 257 bytes Request to server 634538758559585382
00.37.36.056 127.0.0.1:6012 recv 174790 bytes of server Response 634538758560455432
00.37.36.059 127.0.0.1:6012 sent 257 bytes Request to server 634538758560595440
00.37.36.158 127.0.0.1:6012 recv 188491 bytes of server Response 634538758561465490
00.37.36.160 127.0.0.1:6012 sent 257 bytes Request to server 634538758561605498
00.37.36.249 127.0.0.1:6012 recv 178723 bytes of server Response 634538758562491540
00.37.36.249 127.0.0.1:6012 sent 257 bytes Request to server 634538758562491540
00.37.36.373 127.0.0.1:6012 recv 191229 bytes of server Response 634538758563583542
00.37.36.373 127.0.0.1:6012 sent 257 bytes Request to server 634538758563739542
00.37.41.412 client timed out RX operation
  

00.37.35.772 — это hh: mm: ss: ms

634538758557701309 числа в конце строк являются временными метками объектов запроса / ответа для их сопоставления в журналах

Как вы можете видеть, все выполняется должным образом, пока объект 191229 байт не прибудет до его отправки. Клиент не отправляет новый запрос, пока не будет получен ответ. Я не могу понять, как это возможно.

Вполне возможно, что это артефакт ведения журнала. Возможно, какой-то другой поток прервал поток вашего сервера после отправки данных, но до того, как он закрыл журнал.