сбор данны по сети

[Sla]

Да сколько можно намекать?

Какая пропускная способность канала?

[darkelf]

Ну... тут скорей нужна математика.

50Мбит/с ~ 5Мб/с

делим на 600, получаем 8000 пакетов в сек

зы... я не ошибся в расчетах?

Та какая разница, какого размер тик. Пусть будет какой будет.
Я где-то в расчете ошибся?

там, кроме 600 байтов пользовательских данных, будет ещё заголовок TCP (минимум 20 байт), заголовок IP (20 майт), к сожалению не знаю, как в wi-fi, но у ethernet будет ещё MAC-загловок (минимум 22 байта) и его контрольная сумма и межфреймовое пространство (16 байт), т.е. на каждые пользовательские 600 байтов будут расходоваться минимум ещё 80 байт. Далее, т.к. это tcp/ip, а не udp, то тут ещё будет квитирование, т.е. передали данные и ждём подтверждение и так практически на каждое сообщение. Обратно будет идти гораздо меньше данных, но т.к. это запрос-ответ - передающей стороне придётся ждать. Да и как говорил Dimka у самого wi-fi может быть много всяких своих заморочек типа помех.

[Sla]

ну так я ж привел приблизительный расчет.
Я всегда уменьшаю, округляю, как говорил мой преподаватель по ТАУ - меня не интересует точность ваших расчетов до 6 знака. У вас погрешность  измерителей 2%.

[sss]

Вообще хотя бы пинг с 600 байтным пакетом

[Dimka]

Ну вот я свой wi-fi маршрутизатор по стандарту n (до 600 Мб/с), находящийся от меня в паре метров, пингую: начиная с пакета 1200 и времени отклика 1 мс дальнейшее увеличение пакета ведёт к такому же линейному возрастанию времени отклика. 2400 - 2 мс, 4800 - 4 мс, 9600 - 7 мс, 19200 - 13 мс и т.д. При этом у меня в эфире висит 15 точек доступа и, очевидно, не меньшее число клиентов.

[RXL]

Э... не путайте ТС

...........

Как заставить транспорт передать только один пакет получателю?

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

Проблема ТС решается типовым алгоритмом: читать пока не наберется 600 байт.


Добавлено через 4 минуты и 37 секунд:

Итак:
- Какова реальная (наблюдаемая на практике) пропускная способность канала? Сомневаюсь, что там 54 Мб/с (802.11g) или 600 Мб/с (802.11n).
- Какова расчётная пропускная способность канала по условию задачи? Каждую мс по 600 байт 600 000 байт/сек чистых + ну скажем 50% для худшего случая служебного трафика самих сетевых протоколов (разных заголовков, пингов, синхронизаций, повторной передачи битых пакетов и т.п.) - итого округлим до примерно 1 Мб/сек или примерно 8 Мбит/с. Что, в общем-то с большим запасом позволяет любой современный транспорт на близкой дистанции.
- Каковы допустимые задержки при передачи (от момента начала отправки до момента конца получения блока в 600 байт)?

Данный вопрос я уже поднимал. И т.к. некогда детально изучал протокол (на тот момент максимум был 54 Мбит/с), то описал предстоящие трудности и сделал свои оценки: https://forum.shelek.ru/index.php/topic,29445.msg289140.html#msg289140

Добавлено через 5 минут и 3 секунды:

Да сколько можно намекать?

Какая пропускная способность канала?

В первом посте сказано, что 50 Мбит/с. Т.к. таковой скорости не значится в стандартах, предполагаю, что речь о 54 Мбит/с.

[Dimka]

Проблема ТС решается типовым алгоритмом: читать пока не наберется 600 байт.

Проблема может быть ещё и в обработке. Тогда решение будет: читать в одной нити во внутреннюю очередь, а в в другой нити обрабатывать. Ибо каждый запрос на чтение - это, вообще, обращение процесса к ядру, что в масштабе времени 1 мс может быть критичным. И поэтому может возникнуть потребность делать это пореже, читая/записывая много блоков разом - буферизация ввода-вывода.

[Sla]

50 и 54 - не важно и я сказал почему. Для оценки пропускной способности канала

50мбит /10  чтоб получить количество байт в секунду.

получили 5мБ/с - не ошибся?

"блок данных" = 600 байт

считаем сколько таких блоков можем пропустить?
8000 блоков в секунду - не ошибся?

[darkelf]

Если верить http://www.fotonx.ru/index.php/2011-08-17-12-36-50/76--wi-fi.html, то реальная скорость 54Мбит/с и даже 50Мбит/с быть не может, а будет максимум до 24Мбит/с. Ну а дальше, как уже говорилось, накладные расходы, roundtrip-ы в tcp/ip и прочие радости. Возможно 1000 пакетов в секунду можно будет и не набрать.

[Sla]

фух... пост №68

[locator]

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

[darkelf]

locator, wireshark/windump. Winpcap, через которую работают данные программы что-то там вроде умела, правда судя по FAQ (http://www.winpcap.org/misc/faq.htm#Q-16) - работает это не всегда.

[sss]

Правильно - записать каждый байт, не IP пакет... А то вдруг TCP и всё, хана, пропал дом..

[sss]

locator, не помогут всякие wincap. В лучшем случае увидите лог разбитый на "блоки данных" IP, которые надо будет ещё сшивать в поток. Там будут и повторы передач, и регулирование окон и бог его знает что ещё.  

[locator]

darkelf, программа отличная, все что льется в сеть - видно! к тому же еще исходниками.
видно, что мои данные режутся на пакеты размером 1460 байт и 616 байт.
никаких повторов и пропусков не наблюдается. передача идет сильно неравномерно:
много промежуточных пакетов по 70 байт натыкано, и еще какие-то загадочные
пакеты нулевой длины с локального ноута. Я полагаю равномерным такой сбор
данных никогда не сделать.
В передающем потоке поставил Sleep(0), получил обновление данных 815 раз/с.
Большего от данного соединения наверное не получить, но этот результат меня очень
устраивает!

[RXL]

50 и 54 - не важно и я сказал почему. Для оценки пропускной способности канала

50мбит /10  чтоб получить количество байт в секунду.

получили 5мБ/с - не ошибся?

"блок данных" = 600 байт

считаем сколько таких блоков можем пропустить?
8000 блоков в секунду - не ошибся?

Слав, ты ошибся.

[darkelf]

darkelf, программа отличная, все что льется в сеть - видно! к тому же еще исходниками.
В передающем потоке поставил Sleep(0), получил обновление данных 815 раз/с.
Большего от данного соединения наверное не получить, но этот результат меня очень
устраивает!

Как вариант - если потери данных не критичны - попробуйте перейти на UDP - будет шанс получить больший поток за счёт отсутствия ожидания подтверждения, но если приёмник будет не успевать обрабатывать данные, или будут какие помехи - данные будут теряться.

[Dimka]

darkelf, на Wi-Fi UDP - это всегда стрёмно, поскольку не управляешь факторами внешних влияний на сеть. Это по проводу, особенно экранированному, можно более-менее с большой вероятностью быть уверенным.

[locator]

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

[darkelf]

locator, сами данные портится не будут, точнее если будут, то Вы об этом не узнаете - там сам стек считает контрольные суммы, и если что-то не сошлось, то сообщения отбрасываются. Узнать о том, что пакеты побились можно только по их отсутствию.

[RXL]

darkelf, на Wi-Fi UDP - это всегда стрёмно, поскольку не управляешь факторами внешних влияний на сеть. Это по проводу, особенно экранированному, можно более-менее с большой вероятностью быть уверенным.

Приходилось лет 10 назад писать логер для UDP-протокола. Т.к. данные после предобработки загружались в БД, то опасался возможной потери. По этому реализовал следующую архитектуру: приложение многопоточное (приемник, диспетчер, обработчик, две очереди — приема и обработки) прием осуществляется в очередь. Если очередь обработки заполнена ниже порога, диспетчер перебрасывает данные из очереди приема в очередь обработки. Если очередь обработки заполнена, а очередь приема выросла больше порога, создается временный файл в спец.директории и туда сбрасываются данные из приемной очереди, когда очередь на обработку опустеет, сперва подкачаются данные из временных файлов (также при запуске приложения). Система очередей позволяла оперативно принимать большой поток, система с файлами позволяла сглаживать блокировки БД (например при постобработке данных). Для теста искусственно создавал блокировку БД и в буферах в памяти и в файлах накапливалось до сотен МБ и после снятия блокировки все обработалось без потерь. Если памяти достаточно много и гарантия доставки не нужна, то можно обойтись без файлов — только очередь заданий в памяти.

Что-то я неправильно сперва понял процитированое: «на Wi-Fi UDP». Поддерживаю: WiFi дает низкую надежность и для гарантии доставки нужны подтверждения, что съедает плюсы над TCP.

[sss]

Надо просто перейти от синхронного вызова send к асинхронному и при этом остаться в TCP..
TCP пошлёт все как надо - сериями. Подтверждения будут на всю серию.

И про очереди RXL правильно сказал - по другому асинхронно никак.

Хотя вроде уже всё устраивает?

[locator]

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

[sss]

знать интервал времени между последовательными приемами

Где его ещё можно измерить как не на приёмной стороне?

[locator]

можно там где данные сформировались пред передачей, засечь момент времени и запомнить его.
на приемной стороне все склеивается из разрезанных частей, где тут время считать?

[RXL]

Я бы фиксировал время и размер на стороне источника. Лучше данные структуировать, чем ориентироваться на фиксированные блоки. Гибче будет.

[Sla]

в твой  блок данных подключай время.

[Dimka]

Так может и подобие real time не нужно будет, раз время в логах записано.

[locator]

воткнул время в структуру данных, все нормально считается: t = GetTickCount().
ну понятно, с точностью времени расчета самих данных. а если у считающего
данные потока повысить приоритет, время точнее будет определяться?

[darkelf]

воткнул время в структуру данных, все нормально считается: t = GetTickCount().
ну понятно, с точностью времени расчета самих данных. а если у считающего
данные потока повысить приоритет, время точнее будет определяться?

повысить точность можно через API мультимедиа-таймеров, см. timeBeginPeriod()