Подсчитать количество пакетов, отправленных на сервер с клиента?
Итак, я почти выполнил задание, связанное с программированием на Win32 и сокетами, но мне нужно сгенерировать и проанализировать некоторые статистические данные о переносах. Единственная часть, с которой у меня возникают проблемы, - это как определить количество пакетов, отправленных на сервер с клиента.
Отправляемые данные могут быть переменной длины, поэтому я не могу просто разделить общее количество байтов, полученных значением # define'd.
Мы должны использовать асинхронные вызовы, чтобы делать все, поэтому я пытался увеличивать счетчик с каждым сообщением FD_READ, которое я получаю для сокета сервера. Однако, поскольку я должен иметь возможность принимать потенциально большой размер файла, я должен вызывать recv/recvfrom с размером буфера около 64k. Если я отправлю небольшой пакет (az), проблем не будет. Но если я отправлю строку из 1024 символов 10x, сервер сообщит о 2 или 3 полученных пакетах, но потеря данных 0% с точки зрения отправленных / полученных байтов.
Есть идеи, как узнать количество пакетов?
Заранее спасибо:)
3 ответа
Это действительно сводится к тому, что вы подразумеваете под "пакетом".
Как вы, вероятно, знаете, когда по сети отправляется сообщение TCP/UDP, отправляемые данные "обертываются" или с добавлением соответствующего заголовка TCP/UDP. Затем он "оборачивается" в заголовок IP, который, в свою очередь, "оборачивается" в кадр Ethernet. Вы можете увидеть этот прорыв, если вы используете пакет для прослушивания, такой как Wireshark.
Дело в этом. Когда я слышу термин "пакет", я думаю о данных на уровне IP. IP-данные действительно упакованы по проводам, поэтому подсчет пакетов имеет смысл, когда речь идет об IP. Однако, если вы используете обычные сокеты для отправки и получения данных, заголовки IP, а также заголовки TCP/UDP удаляются, т.е. вы не получаете эту информацию из сокета. А без этой информации невозможно определить количество "пакетов" (опять же, я думаю, IP), которые были переданы.
Вы можете сделать то, что предлагают другие, добавив свой собственный заголовок с длиной и счетчиком. Эта информация поможет вам точно определить размер ваших приемных буферов, но не поможет вам определить количество пакетов (опять же, IP...), особенно если вы используете TCP.
Если вы хотите точно определить количество пакетов с помощью сокетов Winsock, я бы предложил создать "сырой" сокет, как предлагается здесь. Этот сокет будет собирать весь IP-трафик, видимый вашей локальной сетевой картой. Используйте заголовки IP и TCP/UDP для фильтрации данных на основе сокетов вашего клиента и сервера, т. Е. IP-адресов и номеров портов. Это даст точную картину того, сколько IP-пакетов было фактически использовано для передачи ваших данных.
У ваших пакетов есть фиксированный заголовок, или вам разрешено определять свой собственный. Если вы можете определить свой собственный, включите счетчик пакетов в заголовок вместе с длиной. Вы должны будете держать промежуточный итог, который учитывает опрокидывание в вашем счетчике, но это будет гарантировать, что вы подсчитываете отправленные пакеты, а не полученные пакеты. При простом назначении вы, вероятно, не столкнетесь с потерей (очевидно, с UDP), но если бы вы были, счетчик пакетов обеспечил бы точность вашей статистики, отражающую отправленное сообщение.
Не прямой ответ на ваш вопрос, а скорее предложение для другого решения.
Что если вы отправите дескриптор длины перед данными, которые вы хотите передать? Таким образом, вы уже можете выделить правильный размер буфера (не слишком много, не слишком мало) на клиенте, а также проверить, не было ли каких-либо потерь при завершении передачи.
С TCP у вас не должно быть никаких проблем, потому что сам протокол обрабатывает безошибочную передачу, иначе вы должны получить значимую ошибку.
Может быть, с помощью UDP вы также можете разделить ваш перевод на куски фиксированного размера с проппид-идентификатором последовательности. Вам нужно будет накапливать все входящие пакеты, прежде чем сортировать их (UDP не дает никаких гарантий на получение-заказа) и вставлять данные вместе.
С другой стороны, вы должны подумать об этом, если это действительно необходимо для поддержки UDP, поскольку есть некоторые ручные накладные расходы, если вы хотите, чтобы этот протокол был защищен от ошибок... (список проблем см. В статье Википедии по TCP). обойти)