Обнаружение, было ли сообщение по tcp передано
Я использую отдельную, но параллельную структуру пакета по нескольким причинам.
- Это сохраняет тесты, организовал тот же путь как код приложения.
- я могу легко создать просто файлы приложения для распределения.
- Тестовый код все еще имеет доступ к моему коду приложения.
- Это не так нарушено как смешивание тестового кода с кодом приложения.
6 ответов
Похоже, этот парень все понял.
РЕДАКТИРОВАТЬ:
Он сделал это с помощью WPF, так что для winforms все будет немного иначе. . Похоже, настоящее золото Awesomium .
Подтверждение не означает, что принимающее приложение получило данные и сделало с ними что-то разумное - все это означает, что отправляющему TCP больше не нужно об этом беспокоиться. Данные могут все еще находиться в пути - например, на промежуточном прокси-сервере или в принимающем стеке TCP.«Данные успешно получены» на самом деле является концепцией уровня приложения - то, что это означает, зависит от приложения (для Например, для многих приложений имеет смысл считать данные «полученными» только после того, как они были синхронизированы с диском на принимающей стороне). Это означает, что вы должны реализовать это самостоятельно, потому что как разработчик приложения вы действительно единственный, кто знает, как сделать это разумно для вашего приложения.
Это означает, что принимающее приложение получило данные и сделало с ними что-то разумное - все это означает, что отправляющему TCP больше не нужно об этом беспокоиться. Данные могут все еще находиться в пути - например, на промежуточном прокси-сервере или в принимающем стеке TCP.«Данные успешно получены» на самом деле является концепцией уровня приложения - то, что это означает, зависит от приложения (для Например, для многих приложений имеет смысл рассматривать данные как «полученные» только после того, как они были синхронизированы с диском на принимающей стороне). Это означает, что вы должны реализовать это самостоятельно, потому что как разработчик приложения вы действительно единственный, кто знает, как сделать это разумно для вашего приложения.
Это означает, что принимающее приложение получило данные и сделало с ними что-то разумное - все это означает, что отправляющему TCP больше не нужно об этом беспокоиться. Данные могут все еще находиться в пути - например, на промежуточном прокси-сервере или в принимающем стеке TCP.«Данные успешно получены» на самом деле является концепцией уровня приложения - то, что это означает, зависит от приложения (для Например, для многих приложений имеет смысл рассматривать данные как «полученные» только после того, как они были синхронизированы с диском на принимающей стороне). Это означает, что вы должны реализовать это самостоятельно, потому что как разработчик приложения вы действительно единственный, кто может знать, как сделать это разумно для вашего приложения.
Данные могут все еще находиться в пути - например, на промежуточном прокси-сервере или в принимающем стеке TCP.«Данные успешно получены» на самом деле является концепцией уровня приложения - то, что это означает, зависит от приложения (для Например, для многих приложений имеет смысл считать данные «полученными» только после того, как они были синхронизированы с диском на принимающей стороне). Это означает, что вы должны реализовать это самостоятельно, потому что как разработчик приложения вы действительно единственный, кто знает, как сделать это разумно для вашего приложения.
Данные могут все еще находиться в пути - например, на промежуточном прокси-сервере или в принимающем стеке TCP.«Данные успешно получены» на самом деле является концепцией уровня приложения - то, что это означает, зависит от приложения (для Например, для многих приложений имеет смысл считать данные «полученными» только после того, как они были синхронизированы с диском на принимающей стороне). Это означает, что вы должны реализовать это самостоятельно, потому что как разработчик приложения вы действительно единственный, кто знает, как сделать это разумно для вашего приложения.
для многих приложений имеет смысл считать данные "полученными" только после того, как они были синхронизированы с диском на принимающей стороне). Это означает, что вы должны реализовать это самостоятельно, потому что как разработчик приложения вы действительно единственный, кто может знать, как сделать это разумно для вашего приложения. для многих приложений имеет смысл считать данные "полученными" только после того, как они были синхронизированы с диском на принимающей стороне). Это означает, что вы должны реализовать это самостоятельно, потому что как разработчик приложения вы действительно единственный, кто знает, как сделать это разумно для вашего приложения.Лучше всего, если получатель отправит подтверждение, даже если это "неловко". Помните, что IP может разбить ваши данные на несколько пакетов и повторно собрать их, и это может быть сделано несколько раз во время передачи, если разные маршрутизаторы в пути имеют разные MTU, и поэтому ваша концепция «пакета» и TCP может не совпадать.
Намного лучше отправить свой «пакет», будь то строка, сериализованный объект или двоичные данные, и попросить получателя выполнить все необходимые проверки, чтобы он оказался там, а затем отправить обратно подтверждение.
1136295]
Протокол TCP очень старается обеспечить поступление ваших данных. Если есть проблема с сетью, он повторно передаст данные несколько раз. Это означает, что все, что вы отправляете, буферизуется, и нет своевременного способа убедиться, что это прибыло (будет тайм-аут через 2 минуты, если сеть не работает).
Если вам нужна быстрая обратная связь, используйте протокол UDP. Он не использует никаких накладных расходов TCP, но вы должны решать все проблемы самостоятельно.
Даже если он добрался до уровня TCP, нет гарантии, что он не находится в буфере приложения, тогда приложение выйдет из строя, прежде чем оно сможет его обработать. Используйте подтверждение, это то, что делает все остальное (например, SMTP)
Прикладной уровень не контролирует уведомления на более низких уровнях (например, на транспортном уровне), если они специально не предусмотрены - это сделано специально. Если вы хотите знать, что TCP делает на уровне пакета, вам нужно узнать на уровне, на котором работает TCP; это означает обработку заголовков TCP и данных ACK.
Однако любой протокол, который вы в конечном итоге используете для передачи полезной нагрузки, может использоваться для передачи сообщений туда и обратно посредством этой полезной нагрузки. Поэтому, если вам неудобно использовать для этого биты заголовка TCP, просто настройте его в своем приложении. Например:
A: Send 450 Bytes
B: Recv 450 Bytes
B: Send 'I got 450 Bytes'
A: Recv 'B got the full message'
A: Continue
Похоже, SCTP может быть чем-то интересным; Я думаю, он должен поддерживать то, что вы хотите. Альтернативой кажется переключиться на UDP, и если вы все равно переключаете протоколы …