Насколько важен Interpacket Gap при отправке пакетов?

Question

Я отправляю некоторые данные с помощью функции сокета write (). На самом деле я использую QT и специально пишу, используя базовую функцию qint64 QIODevice :: write (const QByteArray & byteArray), но вопрос может быть применим и к C.

qint64 QIODevice :: write (const QByteArray & byteArray)реализован так:

inline qint64 write(const QByteArray &data)
{ return write(data.constData(), data.size()); }

Код выглядит примерно так:

// Function, send data once per second using a timer
void sendData()
{
  ...
  ...
  // Create const QByteArray packet1, 100 bytes
  socket->write(packet1);  // packet1 is a const Byte Array
  socket->flush();

  // Create const QByteArray packet2, 1200 bytes
  socket->write(packet2);  // packet2 is a const Byte Array
  socket->flush();

  // Create const QByteArray packet3, 1200 bytes
  socket->write(packet3);  // packet3 is a const Byte Array
  socket->flush();

  return;
}

Все работает хорошо, но примерно 2-3 раза в день, некоторые из пакетных данных (в данныхзаголовок) искажается. Т.е. 2 или 3 пакета отображаются искаженными в течение 24 часов. Эти данные постоянны и не изменяются. Мне интересно, что-то здесь играет.

Мне любопытно - я посылаю данные слишком быстро. Использование waitForBytesWritten () является альтернативой flush (), и меня больше интересует точное определение того, что происходит.

Было бы разумнее вставить небольшой спящий режим между посылками, чтобы Ethernet Interpacket Gap (IPG)) уважается, или это будет слишком грубо?

Answer 1

Из вашего комментария:

В течение 24 часов получатель получает 2 или 3 сообщения с искаженным заголовком сообщения. Таким образом, сообщения имеют протокол прикладного уровня. Большинство сообщений проходят (что-то вроде 86397, в то время как 3 плохие) ...

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

Было бы разумнее вставить небольшой спящий режим между посылками, чтобы разрыва Ethernet Interpacket (IPG) соблюдается, или это будет слишком грубо?

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

Также может быть полезно иметь лучшее обнаружение ошибок на уровне вашего приложения. Использование TLS вместо простого TCP не только обеспечивает шифрование, но и обеспечивает намного лучшее обнаружение ошибок передачи, чем обычный TCP. Вместо этого обнаружения на уровне приложений вы также можете лучше обнаруживать и обрабатывать ошибки на сетевом уровне, используя VPN, такой как IPSec, по существующей ненадежной линии.