Проверьте, успешна ли запись NamedPipeClientStream - PullRequest
Новая
       14

Проверьте, успешна ли запись NamedPipeClientStream

1 голос
/ 23 января 2020

В основном заголовок ... Я хотел бы получить такой же отзыв о погоде NamedPipeServerStream объект успешно получил значение. Это начальный код: 

static void Main(string[] args){
  Console.WriteLine("Client running!");

  NamedPipeClientStream npc = new NamedPipeClientStream("somename");
  npc.Connect();

  // npc.WriteTimeout = 1000; does not work, says it is not supported for this stream
  byte[] message = Encoding.UTF8.GetBytes("Message");
  npc.Write(message);

  int response = npc.ReadByte();
  Console.WriteLine("response; "+response);

}

Я реализовал небольшое эхо-сообщение из NamedPipeServerStream при каждом чтении. Я полагаю, что мог бы добавить некоторое время ожидания asyn c, чтобы проверить, если np c .ReadByte (); вернул значение в допустим 200 мс. Подобно тому, как TCP-пакеты ACKed.

Есть ли лучший способ проверки, если namedPipeClientStream.Write() был успешным?

1 Ответ

1 голос
/ 23 января 2020

Мне бы хотелось, чтобы такой же отзыв о погоде объект NamedPipeServerStream успешно получил значение

Единственный способ точно знать, что отправленные вами данные были получены и успешно обработаны клиент на удаленной конечной точке, для вашего собственного прикладного протокола, чтобы включить такие подтверждения.

Как правило, вы можете предполагать , что если ваши операции отправки успешно завершаются, соединение остается жизнеспособным и удаленная конечная точка получает данные. Если что-то случится с соединением, вы в конечном итоге получите ошибку при отправке данных.

Однако это предположение зашло так далеко. Сетевой ввод / вывод буферизуется, как правило, на нескольких уровнях. Любая из ваших операций отправки почти наверняка предполагает выполнение всего лишь размещения данных в локальном буфере для сетевого уровня. Вызов метода для операции будет возвращен, как только данные будут буферизованы, независимо от того, получила ли удаленная конечная точка их (и фактически почти никогда не получит к моменту возврата вашего вызова).

Поэтому, если и когда такой вызов вызывает исключение или иным образом сообщает об ошибке, вполне возможно, что некоторые из ранее отправленных данных также были потеряны при передаче.

Как наилучшим образом решить эту возможность, зависит от того, что вы ' пытаюсь сделать. Но в целом вам не стоит об этом беспокоиться. Обычно не имеет значения, была ли получена конкретная c передача. Пока вы можете продолжить передачу без ошибок, соединение в порядке, и запрос подтверждения просто лишние накладные расходы.

Если вы хотите обработать случай, когда возникает ошибка, недействительное соединение, заставляющее вас повторить попытку и вы хотите сделать более широкую операцию возобновляемой (например, вы передаете некоторые данные на удаленную конечную точку и хотите убедиться, что все данные были получены, без необходимости повторной отправки данных, которые уже были получены), тогда вы должны создать в протокол вашего приложения - возможность возобновления, когда при повторном подключении удаленной конечной точки сообщается о количестве полученных байтов на данный момент, или о самом последнем идентификаторе сообщения, или о том, какой это протокол вашего приложения, чтобы понять, с чего нужно начинать отправку снова .

См. Также этот очень тесно связанный вопрос (возможно, возможно, даже фактический дубликат… хотя в нем конкретно не упоминаются именованные каналы, почти все сетевые операции ввода-вывода будут связаны с аналогичными проблемами): Гарантирует ли метод записи TcpClient, что данные доставляются на сервер?

Там есть хороший ответ, а также ссылки на еще более полезные вопросы и ответы в этом ответе.

...