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

[sss]

как-то мало волнует - для Вас это просто поток байтов

Файл это поток структурированных данных - при чтении я их последовательно изучаю и в зависимости от прочитанных данных выполняю некоторые действия. А в случае TCP - я читаю столько, сколько дадут - поэтому еще более важна логика чтения!

[Sla]

Могу только порекомендовать для этого modbus внутри tcp

Блок данных запихивать во фрейм modbus, на приемной стороне раскрывать

[sss]

Sla, не знаю - я использую посылку длины, а на приёмной стороне цепочка буферов... По мере наполнения буферов я их выдаю приёмной стороне..

[locator]

разбор потока байтов наверное проще будет сделать, чем во фрейм запихивать

[sss]

Да это логично, а значит проще всего. И если поток постоянный/скоростной не выключай Nagle - быстрее будет.
Ну и плюс попробуй использовать порты завершения - чрезвычайно мощная вещь.

[Sla]

по сути модбас это цепочка байт
фрейм подразумевает, что данные находятся внутри

А если по сети будет идти обмен с несколькими девайсами? Это только сейчас один.

Кроме того, сервер, который собирает эти данные может получать данные и лот других источников, по 485, например.

[darkelf]

как-то мало волнует - для Вас это просто поток байтов

Файл это поток структурированных данных - при чтении я их последовательно изучаю и в зависимости от прочитанных данных выполняю некоторые действия. А в случае TCP - я читаю столько, сколько дадут - поэтому еще более важна логика чтения!

Вы не совсем правы, структуру файла знаете Вы, но никак не ОС/ФС, так-что может это для Вас они структурированы, а для системы - нет, аналогично и с сокетами. Если все сообщения у Вас фиксированной длины - ну тогда вычитывать именно эту длину, и пока всё не прочитал - чтения не завершать, будет всё так-же. Т.е. отличие только в том, что read() Вам всегда (я не рассматриваю ошибки и конец файла) вернёт столько байтов, сколько просите, а recv() - нет, но если написать что-то типа:

Код:

int sock_read(int fd, char* p, int len)
{ int r;
  while (len > 0)
  { r = recv(fd, p, len, 0)
     len -= r;
     p += r;
  }
  return len;
}

то, несмотря на всякие потоки, всё будет работать нормально. Разве-что в этот код добавить проверки ошибок.

[Dimka]

В общем, я так понял, что автор темы полагал передавать по сети свои авторские пакеты по 600 байтов прямо по проводам, но проигнорировал весь стек протоколов.

Совет тут только один. Писать в сокет свои пакеты, как пишется - лишь следить, чтобы каждый пакет записывался целиком, и если это не так, пробовать писать до победы. Аналогично читать пакеты из сокета блоками по те же 600 байтов. Если прочитано меньше, пробовать читать дальше до победы. А как оно там по сети ходит, дробится, какими заголовками обвешивается и как гарантируется безошибочность передачи - это вообще автора не касается, и он не в свою тему полез. Только если для общего развития или любопытства ознакомиться без каких-либо последствий для программной реализации передачи.

Останется только следить: а) за скоростью передачи, чтобы пропускная способность каналов была достаточной, и чтобы стороны не тормозили сами по себе; б) обработку ситуации обрыва связи, чтобы стороны не зависали в безуспешных попытках чтения/записи - обычно решается при помощи таймаута, что если, допустим столько-то секунд "не алё", то связь считается оборванной.

[sss]

Да я уже не спорю.. Допустим есть такое понятие - потоковое вещание. При этом есть реализации и в UDP и в TCP. Я пытаюсь сказать что есть различие между понятием потоковый и дейтаграммный сокет, а не потоковый и пакетный. В чём разница между вызовом recv на UDP и TCP сокете ? Её нет. Это я про скрытие реализации..

[darkelf]

Да я уже не спорю.. Допустим есть такое понятие - потоковое вещание. При этом есть реализации и в UDP и в TCP. Я пытаюсь сказать что есть различие между понятием потоковый и дейтаграммный сокет, а не потоковый и пакетный. В чём разница между вызовом recv на UDP и TCP сокете ? Её нет. Это я про скрытие реализации..

там "потоковое" это, имхо, немного другое "потоковое", чем здесь.

[Dimka]

sss, признаться, я вообще не понимаю о чём ты говоришь. Это как пытаться рассуждать о том, что свёкла - это не морковка, хотя обе - корнеплоды. И что с того?

[sss]

признаться, свёкла - это не морковка. И что с того?

Хотите прекратить досужие споры переведя тему в плоскость философии? Я бы рад, но увольте. Попробую остаться в плоскости сетей.

 - Ответьте на вопрос почему вначале темы возникли вопросы - сокет UDP или TCP?
 - Потому что в контексте вызова на сокете нет разницы какой он - назовём это сокрытием реализации.
 - Ура! Сокрытие реализации поточной передачи! Тогда почему я не могу рассматривать передачу как пакетную передаваемую через поток?
 - Потому что это TCP.
 - Так ведь TCP использует пакеты (FIN, ACK, RST)?
 - Это сокрытие реализации.

Заколдованный круг рассуждений. Я как раз предлагаю не заострять внимание на терминах и не считать одним и тем же понятие - пакет и дейтаграмма!

[RXL]

Ну и сам же ушел в философию...
Давай говорить сухо и по делу.

1. Протоколы TCP и UDP представляют две разные транспортные концепции: байтовый поток и дейтаграмма.
2. В потоке размер IP пакета не коррелирует с размером отсылаемой структуры, но пакет IP включает дейтаграмму целиком.
3. Поток не лимитирован по размеру. Дейтаграммы ограничены реализацией стека протоколов (ограничение может быть в рамках MTU или используется фрагментация большого пакета при отсылке).
4. Для выделения полученной структуры данных в потоке необходимо определять начало и конец или размер этой структуры, в дейтаграмме надо лишь задать достаточный по размеру буфер приема.

Совершенно разный подход!
Не говоря уже о различиях в гарантии доставки.

Если в чем сомневаешься, штудируй Стивенсона. Если не сомневаешься — тем более штудируй. Попутно не забывай про Winsock.

[sss]

Между прочим, теперь в твоих формулировках вообще не вижу ничего спорного. Пакеты для создания гарантированных потоков, пакеты же для создания потока дейтаграмм и пакетирование для выявления полученных структур - другой способ маркеры конца. Получив очередной буфер вне зависимости от транспорта хочу иметь право говорить - парсинг принятого пакета. А вы мне категорично это запрещаете - говорите в TCP нет пакетов. Вообще можно вообще ответить - при чём здесь TCP? TCP только транспорт!
Например службы DNS - пожалуйста хотите используйте UDP или TCP но доставляют они пакеты DNS!

P.S.: Опять скажут что сравниваю что то не то.

Добавлено через 5 минут и 42 секунды:
Тут вообще как всё началось - кто то сказал что использует TCP и при этом портятся данные (логические пакеты пользователя). Ему ответили - TCP не бьёт пакеты и вообще там нет пакетов и понеслась...  А я пытаюсь сказать, что TCP выполняет огромную работу по транспорту при этом не гарантируя (внимание) соблюдения границ сообщений пользователя (логических пакетов пользователя).

[Sla]

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

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

И вот он отдает свой блок данных,  а отправитель, чтоб не растрачивать ресурсы и не гонять порожняком ждет еще данных.
Когда времени хватает (с задержкой) то носитель, не дождавшись уже уехал и привез 600байт.
А вот когда все время идет пересылка,  то его данные разбиваются, а получатель об это не знает, и говорит, что посылка битая.

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

[darkelf]

И вот он отдает свой блок данных,  а отправитель, чтоб не растрачивать ресурсы и не гонять порожняком ждет еще данных.
Когда времени хватает (с задержкой) то носитель, не дождавшись уже уехал и привез 600байт.
А вот когда все время идет пересылка,  то его данные разбиваются, а получатель об это не знает, и говорит, что посылка битая.

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

там проблема не только в передаче, а и в приёме. Причем если правильно организовать приём, то как там оно передаёт уже особо не важно.

[sss]

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

Тут можно выключить Nagle. Только не поможет если много маршрутизаторов на пути. Придут, например, по 100 + 100 + 400
Вот не знаю - дейтаграммы сегментируются или нет? Думаю молча отбрасываются если не влезают..

[locator]

однако, в сети глубоко залезешь - обратно не вылезешь 
прилепил в начале своей структуры заголовок, на приемной
стороне все буферы собираются в цепочку - все ок, все пакеты
нормально принимаются.  Получилось примерно 35 раз/сек.
А ускорить никак нельзя ? Можно поподробнее про настройку Nagle?

[sss]

Что то очень медленно. Какой на передающей стороне код ?

Про Nagle смотри опцию TCP_NODELAY

http://msdn.microsoft.com/en-us/library/windows/desktop/ms738596%28v=vs.85%29.aspx

[Dimka]

Согласен со Sla: кто вообще решил, что по условию задачи непременно надо, чтобы по сети на всех уровнях путешествовали пакеты (на уровне IP) и фреймы (на уровне Ethernet), вмешающие в себе непременно все 600 байт? Это создавать себе проблему на ровном месте.

Имеет значение только поток пользовательских байтов. То, что он делится на блоки по 600 байт, это сетевые протоколы не волнует. Игры со всякими MTU и прочим - это лишь мероприятия по оптимизации потока, чтобы фрагментация была меньше, и нагрузка на хосты и маршрутизаторы была ниже, а также была бы меньше задержка.

Главный вопрос: какая пропускная способность канала в пользовательских байтах/сек нужна, и какая задержка в прохождении информации допустима? Ни автор темы, ни кто другой почему-то этих вопросов не ставит, хотя они - основа для выбора сетевого транспорта как в части протоколов, так и в аппаратной части.

Кроме того, Wi-Fi - это среда фактически "с общей шиной" (в терминах Ethernet), т.е. помехи в эфире или другие точки на том же канале приводят к резкому снижению скорости. И если в проводных сетях эта проблема решается изоляцией сегментов канального уровня через коммутаторы, то в радиоэфире это невозможно. Поэтому говорить о 54 Мб/с оправдано лишь в идеальных условиях: когда на канале нет других точек и иных помех (от грозы до иной техники). Наконец, и расстояние имеет значение, и качество, и мощность передающих и принимающих устройств.

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

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

[Sla]

Главный вопрос: какая пропускная способность канала в пользовательских байтах/сек нужна, и какая задержка в прохождении информации допустима? Ни автор темы, ни кто другой почему-то этих вопросов не ставит

Я пАпрАшу...
Это было во втором посте.

[locator]

ну вот такой код на стороне передающего клиента

Код: (C++)

while(1)
    {
          send(my_sock, buf, sizeof(_DEV_DATA), 0);
          Sleep(10);
    }

должен 100 раз в секунду передавать

[darkelf]

ну вот такой код на стороне передающего клиента

Код: (C++)

while(1)
    {
          send(my_sock, buf, sizeof(_DEV_DATA), 0);
          Sleep(10);
    }

должен 100 раз в секунду передавать

к сожалению - не должен. Sleep(10) ждёт как минимум 10 миллисекунд, а как максимум - в зависимости от загрузки машины. В некоторых случаях даже при Sleep(10) и отсутствии дополнительных действий, он будет всегда ждать как минимум 15(или 16) миллисекунд, т.к. системный тик в Windows будет именно таким.

[Sla]

darkelf, это не суть важно

[locator]

а я Sleep(1) ставил, скорость практически не растет

[Dimka]

locator, во-первых, если у тебя такой цикл, то как ты измеряешь скорость? Где собственно код измерения скорости?

Во-вторых, это код передающей стороны, а как обстоит дело на принимающей? Может у тебя там машина "зашивается" при парсинге или в каких-либо обработках. Разумеется, буферы не резиновые, и передача будет идти не быстрее, чем приём.

В-третьих, ты ничего не сказал по поводу Wi-Fi. Например, с какой скоростью происходит копирование большого файла между соединёнными Wi-Fi машинами? Может там у тебя эфир такой, что и 1 Мб/с - роскошь.

[darkelf]

darkelf, это не суть важно

Sla, просто в данном случае рассчитывать на 100 пакетов в секунду как-бы вообще не приходится, даже на гигабитном ethernet-е (т.к. проблема вовсе не в нём), что уже говорить про wi-fi.

[sss]

а я Sleep(1) ставил, скорость практически не растет

Так ты счётчик за секунду посчитай и поймешь сколько у тебя вызовов в секунду.. Получается ты блокируешься в send. Переходи к перекрытому вводу выводу..

[Sla]

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

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

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

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

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

[sss]

Я где-то в расчете ошибся?

Специфика WiFi большие задержки перехода в эфир.. При этом используется синхронный вызов отправки с ожиданием результата.