Подсчитать количество пакетов, отправленных на сервер с клиента?

Question

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

Отправляемые данные могут быть переменной длины, поэтому я не могу просто разделить общее количество байтов, полученных значением # define'd.

Мы должны использовать асинхронные вызовы для выполнения всего, поэтому я пытался увеличивать счетчик с каждым сообщением FD_READ, которое я получаю для сокета сервера. Однако, поскольку я должен принимать потенциально большой размер файла, я должен вызывать recv / recvfrom с размером буфера около 64 КБ. Если я отправлю небольшой пакет (a-z), проблем не будет. Но если я отправлю строку из 1024 символов 10x, сервер сообщит о 2 или 3 полученных пакетах, но 0% потери данных с точки зрения отправленных / полученных байтов.

Есть идеи, как узнать количество пакетов?

Заранее спасибо:)

Answer 1

Это действительно сводится к тому, что вы подразумеваете под «пакетом».

Как вы, вероятно, знаете, при отправке сообщения TCP / UDP по проводной линии отправляемые данные «переносятся» или добавляются с соответствующим заголовком TCP / UDP. Затем он «оборачивается» в заголовок IP, который, в свою очередь, «оборачивается» в кадр Ethernet. Вы можете увидеть этот прорыв, если вы используете пакет сниффинга, такой как Wireshark.

Дело в том. Когда я слышу термин «пакет», я думаю о данных на уровне IP. IP-данные действительно упакованы по проводам, поэтому подсчет пакетов имеет смысл, когда речь идет об IP. Однако, если вы используете обычные сокеты для отправки и получения ваших данных, заголовки IP, а также заголовки TCP / UDP удаляются, то есть вы не получаете эту информацию из сокета. А без этой информации невозможно определить количество «пакетов» (опять же, я думаю, IP), которые были переданы.

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

Если вы хотите точно определить количество пакетов с использованием сокетов Winsock, я бы предложил создать «сырой» сокет, как предложено здесь . Этот сокет будет собирать весь IP-трафик, видимый вашей локальной сетевой картой. Используйте заголовки IP и TCP / UDP для фильтрации данных на основе сокетов вашего клиента и сервера, то есть IP-адресов и номеров портов. Это даст точную картину того, сколько IP-пакетов было фактически использовано для передачи ваших данных.

Answer 2

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

Answer 3

Не прямой ответ на ваш вопрос, а скорее предложение другого решения.

Что если вы отправите дескриптор длины перед данными, которые вы хотите передать? Таким образом, вы уже можете выделить правильный размер буфера (не слишком много, не слишком мало) на клиенте, а также проверить, не было ли каких-либо потерь при завершении передачи.

С TCP у вас не должно быть никаких проблем, потому что сам протокол обрабатывает безошибочную передачу, иначе вы должны получить значимую ошибку.

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

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