Как я могу проверить, что пакет TCP получил ACK в C#?

Я рекомендую использовать Pcap.Net .

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

Вы также можете легко создавать и отправлять пакеты.

Вы заставляете другой конец реагировать на это.

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

Эта информация недоступна в библиотеках классов .net. У меня были те же соображения, когда я начал работать над этим сканером портов на C #. Я использовал .NET-оболочку для libpcap (после установки соответствующего драйвера), SharpPcap ( http://sourceforge.net/projects/sharppcap/ ), чтобы получить такую ​​информацию. . Пакеты ACK получаются через интерфейс SharpPcap (прозрачно вызывая собственный интерфейс libpcap).

Мое приложение - NScanner Port Scanner / Sweeper, и вы можете найти код в codeplex, ссылаясь на мое простое использование вышеупомянутой библиотеки ( http://nscanner.codeplex.com/ ). 1237] Надеюсь, я помог.

Если вы действительно уверены, что вам нужно знать детали уровня пакетов вашего TCP-соединения, тогда в Помимо создания TCP-сокета для отправки, вам нужно, чтобы ваше приложение использовало API winpcap для просмотра необработанного трафика. Вы можете установить фильтр только для приема пакетов, относящихся к конкретному IP-адресу и комбинации портов, которая определяет вашу удаленную сторону.

Есть несколько проектов, создающих .NET-оболочки для libpcap, например здесь

Уровень TCP будет продолжайте повторно отправлять пакет до тех пор, пока он не получит успешный ACK.

Send будет блокироваться, пока это не произойдет - SendAsync не будет блокировать, и вы можете продолжить обработку других данных, пока уровень TCP обрабатывает отправку пакета.

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

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

Возьмем HTTP в качестве примера протокола «Streaming like». Сервер отправляет поток данных клиенту. Больше нет дополнительных «ACK» прикладного уровня, и серверу на самом деле все равно, когда и как именно поступит его поток данных. Это очень эффективно для каналов с высокой задержкой.

Теперь сравните это с SMB! Вместо потоковой передачи файла данные разбиты на блоки. Каждый успешно переданный блок данных проверяется на уровне приложения. Это дает вам больше контроля, однако эффективно уничтожает протокол в сетях WAN (см. «Продукт задержки полосы пропускания»).

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