Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: 1 [2] 3  Все   Вниз
  Печать  
Автор Тема: сбор данны по сети  (Прочитано 99792 раз)
0 Пользователей и 1 Гость смотрят эту тему.
sss
Специалист

ru
Offline Offline

« Ответ #30 : 10-06-2013 06:51 » 

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

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

while (8==8)
Sla
Команда клуба

ua
Offline Offline
Пол: Мужской

WWW
« Ответ #31 : 10-06-2013 06:52 » new

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

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

Мы все учились понемногу... Чему-нибудь и как-нибудь.
sss
Специалист

ru
Offline Offline

« Ответ #32 : 10-06-2013 06:55 » 

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

while (8==8)
locator
Постоялец

ru
Offline Offline

« Ответ #33 : 10-06-2013 06:56 » 

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

ru
Offline Offline

« Ответ #34 : 10-06-2013 06:59 » 

Да это логично, а значит проще всего. И если поток постоянный/скоростной не выключай Nagle - быстрее будет.
Ну и плюс попробуй использовать порты завершения - чрезвычайно мощная вещь.
« Последнее редактирование: 10-06-2013 07:01 от sss » Записан

while (8==8)
Sla
Команда клуба

ua
Offline Offline
Пол: Мужской

WWW
« Ответ #35 : 10-06-2013 07:05 » 

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

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

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

Записан

Мы все учились понемногу... Чему-нибудь и как-нибудь.
darkelf
Молодой специалист

no
Offline Offline

« Ответ #36 : 10-06-2013 10:17 » 

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

Файл это поток структурированных данных - при чтении я их последовательно изучаю и в зависимости от прочитанных данных выполняю некоторые действия. А в случае 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;
}
то, несмотря на всякие потоки, всё будет работать нормально. Разве-что в этот код добавить проверки ошибок.
« Последнее редактирование: 10-06-2013 10:19 от darkelf » Записан
Dimka
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #37 : 10-06-2013 13:43 » 

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

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

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

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
sss
Специалист

ru
Offline Offline

« Ответ #38 : 10-06-2013 13:45 » 

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

while (8==8)
darkelf
Молодой специалист

no
Offline Offline

« Ответ #39 : 10-06-2013 14:02 » 

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

ru
Offline Offline
Пол: Мужской

« Ответ #40 : 10-06-2013 16:00 » 

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

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
sss
Специалист

ru
Offline Offline

« Ответ #41 : 11-06-2013 01:43 » 


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

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

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

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


Записан

while (8==8)
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #42 : 11-06-2013 06:29 » 

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

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

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

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

« Последнее редактирование: 11-06-2013 06:31 от RXL » Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
sss
Специалист

ru
Offline Offline

« Ответ #43 : 11-06-2013 07:06 » 

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

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

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

while (8==8)
Sla
Команда клуба

ua
Offline Offline
Пол: Мужской

WWW
« Ответ #44 : 11-06-2013 07:19 » 

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

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

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

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

Мы все учились понемногу... Чему-нибудь и как-нибудь.
darkelf
Молодой специалист

no
Offline Offline

« Ответ #45 : 11-06-2013 07:22 » 

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

зы мне кажется такое видение.
Как заставить транспорт передать только один пакет получателю?
там проблема не только в передаче, а и в приёме. Причем если правильно организовать приём, то как там оно передаёт уже особо не важно.
Записан
sss
Специалист

ru
Offline Offline

« Ответ #46 : 11-06-2013 07:23 » 

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

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

while (8==8)
locator
Постоялец

ru
Offline Offline

« Ответ #47 : 11-06-2013 07:34 » 

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

ru
Offline Offline

« Ответ #48 : 11-06-2013 07:42 » 

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

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

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


Записан

while (8==8)
Dimka
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #49 : 11-06-2013 09:24 » 

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

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

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

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

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

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

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
Sla
Команда клуба

ua
Offline Offline
Пол: Мужской

WWW
« Ответ #50 : 11-06-2013 09:37 » 

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

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

Мы все учились понемногу... Чему-нибудь и как-нибудь.
locator
Постоялец

ru
Offline Offline

« Ответ #51 : 11-06-2013 09:38 » 

ну вот такой код на стороне передающего клиента
Код: (C++)
while(1)
    {
          send(my_sock, buf, sizeof(_DEV_DATA), 0);
          Sleep(10);
    }
должен 100 раз в секунду передавать
Записан
darkelf
Молодой специалист

no
Offline Offline

« Ответ #52 : 11-06-2013 09:42 » 

ну вот такой код на стороне передающего клиента
Код: (C++)
while(1)
    {
          send(my_sock, buf, sizeof(_DEV_DATA), 0);
          Sleep(10);
    }
должен 100 раз в секунду передавать
к сожалению - не должен. Sleep(10) ждёт как минимум 10 миллисекунд, а как максимум - в зависимости от загрузки машины. В некоторых случаях даже при Sleep(10) и отсутствии дополнительных действий, он будет всегда ждать как минимум 15(или 16) миллисекунд, т.к. системный тик в Windows будет именно таким.
Записан
Sla
Команда клуба

ua
Offline Offline
Пол: Мужской

WWW
« Ответ #53 : 11-06-2013 09:44 » 

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

Мы все учились понемногу... Чему-нибудь и как-нибудь.
locator
Постоялец

ru
Offline Offline

« Ответ #54 : 11-06-2013 09:47 » 

а я Sleep(1) ставил, скорость практически не растет
Записан
Dimka
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #55 : 11-06-2013 10:19 » 

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

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

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

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
darkelf
Молодой специалист

no
Offline Offline

« Ответ #56 : 11-06-2013 10:23 » 

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

ru
Offline Offline

« Ответ #57 : 11-06-2013 10:41 » 

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

Так ты счётчик за секунду посчитай и поймешь сколько у тебя вызовов в секунду.. Получается ты блокируешься в send. Переходи к перекрытому вводу выводу..
« Последнее редактирование: 11-06-2013 10:43 от sss » Записан

while (8==8)
Sla
Команда клуба

ua
Offline Offline
Пол: Мужской

WWW
« Ответ #58 : 11-06-2013 10:43 » 

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

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

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

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

Мы все учились понемногу... Чему-нибудь и как-нибудь.
sss
Специалист

ru
Offline Offline

« Ответ #59 : 11-06-2013 10:48 » 

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

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

while (8==8)
Страниц: 1 [2] 3  Все   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines