alx125

"Прилетит" на оборудование оператора, но не будет модулем подтвержден, а значит и тарифицирован. Но эта гипотеза требует проверки Если цель одна - надежность доставки,то преимущества TCP очевидны! А чтобы не получать ответы Web-сервера (а именно они больше всего волнуют автора топика) можно порекомендовать использовать не связку HTTP-TCP, а только TCP-сокеты. Кроме того, на нем легче осуществить идентификацию отправителя. Для UDP есть свои ниши. Недаром он не умер в процессе эволюции. На нем достигается многоадресная рассылка, быстрота передачи - нет периода установления соединения, минимум трафика, например. Есть масса приложений в которых TCP не имеет преимуществ. Например потоковое аудио и видео. Часто Вы видите/слышите сбой при приеме мультимедиа on-line? Если бы там было 5-10% потерь пакетов, уже слушать/смотреть нельзя было бы! А объем-то передан какой! Не то что в текущей задаче :rolleyes: Или классический пример - служба времени. В любом из этих случаев повторять утерянные пакеты бессмысленно. Кстати, для службы DNS не менее важна надежность, но она обычно функционирует на UDP. А перевести ее админу на TCP не тривиальная задача! А автор топика написал: "...Это было бы идеальным вариантом ....А уверенность о доставке мне не нужна... пока...." После того как Вам удалось зарегистрировать и привязать серверный сокет - порт уже Ваш и демон будет вызывать именно Ваш скрипт. Так что другие порты уже не должны волновать. Не совсем понятно назначение NAT для сервера ЦОД? Как тогда до него "достучаться"? Поясните пожалуйста. Если речь идет про клиентов запускающихся по cron (или иначе) на сервере и внутреннюю инфраструктуру ЦОД, то они нас разве волнуют? Сейчас провел эксперимент. Для клиента (в смысле архитектура "клиент-сервер") на хостинге действуй PAT. А IP-адрес не меняется даже для него.

Вопрос с блокировкой UDP-портов (впрочем не только их) виртуального хостинга решается в индивидуальном порядке с администратором. Или же ищется хостинг под задачи - что не редкость! Я задал этот вопрос двум хостинговым компаниям и получил ответ - "Мы разрешаем UDP". Я также спросил и у Вашего провайдера (адрес взял из вашего скрипта) - он не ответил. Задайте этот вопрос админу хостинга сами. Ведь Вы его клиент. Обычный подход для безопасности - запретить сначала по-максимуму, а потом задействовать что-то по мере необходимости. Большинству клиентов хостинга эта возможность (UDP-сокеты) не нужна. Но дело тут не только в безопасности. Особенностью TCP является регулирование нагрузки на канал в зависимости от его (канала) загрузки. Это делается с помощью "скользящего окна". Своего рода обратная связь (регулировочный "винтик") как в электронике и т.п. Именно поэтому при старте TCP сначала идет так называемая "фаза медлеленного старта" с маленьким "скользящим окном" и далее оно увеличивается до момента потери большого числа пакетов. При одновременной передачей на канале UDP (например VoIP) и TCP покетов - сложнее, т.к. UDP пытается сразу использовать канал по-максимуму не чувствуя текущей загрузки канала! Тем самым потери TCP-покетов возрастают, а далее TCP передачи снова начинаются с маленьких "скользящих окон". Что плохо для соседних сайтов! Это особенно актуально для виртуального хостинга, где все дешево и ресурсов по-минимуму и есть взаимовлияние быстродействия сайтов от загрузки соседних на одном IP-адресе. В Вашем случае трафик, судя по всему, минимален (претензий администратора не будет), а следовательно может получиться. Но лучше подойдет для этого виртуальный сервер, где ширина канала (нагрузка на CPU в данном случае не важна) гарантирована. Чуть дороже зато решит Ваши задачи с UDP-сокетами. Для Вашего случая он может даже самоокупиться по сравнению с использованием TCP-HTTP протоколов. По поводу нехватки портов в системе. Как известно их >60тысяч для UDP и столько же для TCP ("Хорошо известные" и доп. я грубо вычел) В случае виртуального хостинга на одном IP-адресе находится от нескольких десятков до несколько сотен сайтов (у меня это - 260 шт) Так что свободных портов (особенно UDP) "завались" по определению. А если у сервера несколько IP - то и больше. Есть только такой момент - если порт выделен операционной системой по запросу, из скрипта вернуть его в пул системы не получится. Есть еще несколько соображений как получить подходящий результат простыми средствами. Попытаться использовать AT-команды (я рассматриваю SimCom): Вариант 1). AT+CIPCLOSE - закрыть TCP соединение ч/з некоторое время после отправки запроса. При этом PDP контекст остается активен и не начнется новый период тарификации! Вариант 2). AT+CLPORT - сменить порт ч/з некоторое время после отправки TCP-запроса. Ответ Web-сервера поступит, но не будет подтвержден модулем, а значит не будет и тарифицирован. Задержка сброса соединения и смены порта подбирается экспериментально (например 0,5с),т.к. эта часть встроенного TCP-стека модуля наверняка работает в отдельном потоке и не предсказуема. Конечно это только гипотеза требующая проверки на реальной реализации.

Про реализации и особенности UDP-сервера можно познакомиться например в кн. "Разработка сетевых программ на Perl" Но все это возможно и на PHP.

Вы бы уточнили про какой размер трафика запроса/ответа идет речь! Чтобы можно было понять чей это ответ - TCP или Web-сервера или серверного скрипта Сервер и скрипт Ваши? Что он отвечает точно понятно? Или это чужая реализация? Если Вы хотите чтобы входящего трафика с сервера не было вообще - транспорт TCP не подойдет. Т.к. он по определению подразумевает обмен и наклодные затраты - синхронизация, квитирование, повтор при потере ... Сброс флага RST в заголовке TCP не подойдет (даже если бы у Вас был внешний стек), т.к. не угодать с моментом его установки! Он должен установлен и отослан уже после получения запроса Web-сервером и скриптом, но до ответа! Что не реально! Прямое подключение к сетевой СУБД MySQL- тоже не спасет, т.к. используется транспорт TCP тоже. Если необходимо минимизировать трафик, и в частности входящий от ответа сервера - используйте UDP. Но платой за это является отсутствие уверенности о доставке Ваших данных! Впрочем, что-то простое здесь можно и самому предложить в зависимости от ТЗ. Совсем уж доводить до нескольких сотен байт мобильный трафик вряд ли уместно, т.к. существует округление в большую сторону у операторов. Если же Вы расчитываете использовать нетарифицируемый интервал (есть на некоторых тарифах ~ <2кб), то тоже сомнительно. Как я ранее описывал на форуме такую ситуацию у меня - оператор просто заблокировал не несколько недель целевой IP. Правды у него (GSM-оператора) добиться не удалось. И мне пришлость использовать proxy. Но трафик уже был болеее 2кб. А значит округлялся до 100 кб :(

Похожие технологии применяют для высоконагруженных сайтов. Когда запросы направленные по одному и тому же доменному имени распределяются Веб-сервером по разным физическим серверам в целях балансирования нагрузки. Как побочный эффект получается и увеличение надежности. Также возможен подход с применением Proxy-серверов Или например такой подход (впрочем это тоже proxy) как "URL Shorteners" Например: http://tinyurl.com/ или http://bit.ly/ Правда в этом случае управление будет ручное :rolleyes: Эти внешние подходы подойдут когда нельзя вмешаться в код M2M устройства В противном случае лучше конечно реализация резервного доменного имени (или IP-адреса) на уровне кода программы. Или другой вариант. Ваша программа в случае неудачного доступа к серверу могла бы где-то во вне (например на xxx.narod.ru) запросить другие новые варианты URL.

Если Вы оплатили статический внутренний IP-адрес, то Вы его и получаете. В данном случае статический - значит всегда один и тот же при любом подключении. 10.217.67.207 - это из диапазона отведенного для внутренних адресов! Если Вы купили еще и публичный (внешний) IP-адрес, то AT+CIFSR не выдаст, а только внутренний Хотя, в этом случае он Вам должен быть известен.... Вы же его покупали ;-) Пользуйтесь например http://whatismyipaddress.com/ или напишите свою реализацию возврата IP-адреса запроса Кстати, при публичном IP необходимо что-то предпринять против ненужного трафика иначе Вас разорят внешними запросами

1.В обычном случае (если не оплачивали статический) Вы получите внутренний динамически выданный Вам оператором IP-адрес Внешний же (тоже кстати динамический) можно узнать обратившись например по http://whatismyipaddress.com/ Если хотите (и даже проще), это можно сделать из браузера сотового телефона 2. Нет

Как я понял из приведенной ранее мной монографии - все же TA можно использовать, но только лишь как дополнительный параметр. А не как самостоятельный и самодостаточный. А вообще - мы не первые. Все эти идеи уже исследованы и опробованы. Написаны монографии. Пожалуй интересней те возможности, что открывают новые стандарты. Например 3G Дело в том, что там возможности мобильного позиционирования были изначально более широкие, чем в GSM.

По моим наблюдениям переключения (оператором, при регулировании нагрузки на соту) на разные базы (даже в стационарных условиях) происходит не так уж и редко А в движении и еще чаще! Особенно, если периодически инициировать (не доводя до реального) вызовы. Так что теоретически параметром TA (The timing advance) можно было бы реально пользоваться. Однако! Если посмотреть монографию "Mobile Positioning and Tracking. From Conventional to Cooperative Techniques" 2010г выпуска то на страницах 191-192 можно познакомиться с реальными исследованиями применения этого метода мобильного позиционирования. После теоретических и практических выкладок делаются выводы для метода TA: In field measurements, the average of the absolute distance estimation error was about 217 m when the linear approximation in Figure 8.7 was used. В то же время для "...On the other hand, the cell IDs and the RSSIs.. " (т.е. когда TA не применяется, а только cell ID и RSSI): "...The median corresponds to an estimation accuracy of 117 m..." Вот и делайте выводы...

Маленькое уточнение: http://www.opencellid.org/ Без 2-х "e" :rolleyes:

Шины бывают разные Между ними бываю шлюзы

А трафик дополнительный тоже есть? Если нет - то так ли это важно. И сколько времени это продолжается? Не вечно же

"белые-черные" - это слэнг (жаргон). Синоним "внутренние и внешние".

Назначение GSM-провайдером публичного IP-адреса вашему устройству (неважно динамический или статический) это скорее огромное исключение, чем правило (мне кстати с таким сталкиваться не приходилось), которое имеет и свои отрицательные стороны - ухудшение безопасности и др. В большинстве случаев назначается IP-адрес не public-диапазона. А для этого случая не существует AT-команд (т.к. этот уровень назначения адреса находится далеко за пределами вашего устройства ), которые позволяют получить IP-адрес после NAT. Только запрос в внешнему серверу. Например, с помощью HTTP. И еще, статический адрес - не значит pubic.

Уточните про какой динамический IP-адрес Вы говорите - внутренний или внешний? Это принципиально! Например, внешний динамический IP-адрес можно узнать только извне. Например ч/з HTTP-запрос. А внутренний IP-адрес далеко не всегда можно напрямую использовать. Возможность его применения зависит от ТЗ и настроения GSM-оператора. В общем случае без внешнего посредника (сервера) обойтись трудно.

Необходимо только принять во внимание, что хоть RFC 4787 и дает рекомендации по поведению NAT, реально существует 3 варианта реализации функциональности NAT, каждый из которых имеет свои особенности и ограничения. Вы описали только первый, который применяется в методе "Hole Punching" для так называемых NAT Traversal Techniques. Это как раз и учитывается при построении пиринговых коммуникаций (P2P). Особенно это актуально для мобильной связи, когда оператор GSM часто может меняться.

Если Ваш клиент не будет передавать HTTP заголовок типа Content-Encoding: x-gzip, то Вам эта проблема не грозит. Сервер не будет сжимать передаваемое содержимое. Ну и трафик конечно будет побольше :rolleyes:

Я поступал также, но думаю есть решения более сильные :rolleyes:

Здравствуйте. Может кто-то знает публично доступный качественный parser для разбора AT-команд GSM-модулей? Дайте ссылочку. Или же все (как и я) для этого используют стандартную библиотеку С работы со строками?

Не все аккумуляторы подходят для этой цели. Только емкости мало! Важен также такой параметр как максимальный ток разряда. Понятно что это связано в первую очередь с внутренним сопротивлением. Именно поэтому производители модулей часто рекомендуют конкретных производителей и модели. Уточните для своего типа аккумулятора, чтобы быть уверенным!

Хорошие цены и пр. У Вас там уже коммунизм? :rolleyes:

Nokia PT-6. Видео-фото, звук, детектор движения и др. Но снята уже с производства. Есть несколько альтернативных решений др.производителей. Нужно просто признать что нам (обсуждающим здесь) просто не известно публично-доступное решение надежного декодирования DTMF в GSM. Его не знают ни "махровые радиолюбители", ни профессионалы. :rolleyes: Но оно существует! Только связано с существенными трудозатратами в разработке. Кстати, обратите внимание что никто здесь даже не пытается загадочно сказать, что он имеет надежное решение данной задачи, но не может поделится потому что оно коммерческое. :rolleyes:

БПФ - быстрое преобразование Фурье (это не ДПФ!) является исключительным порождением цифровой обработки сигналов. Это даже семейство цифровых алгоритмов, а не один. Наверное, при желании, БПФ все же можно реализовать и на десятках-сотнях операционных усилителей, запоминающих аналоговых ячейках, аналоговых коммутаторах, аналоговых умножителях-модуляторах для операции "бабочка" и огромной схеме управления и т.п. Но это скорее всего имеет только академический смыл (книга кстати 30летней давности!), чем практический. И будет она не чисто аналоговой, а дискретной! Тем более, что основой всех цифровых микросхем является транзистор. Т.е аналоговый элемент. Но который в этом случае работает в ключевом (читай -цифровом) режиме. Понятно, что окружающий нас мир по своей сути "аналоговый". Но как показали последние годы апроксимация "аналогового мира" при помощи цифры открывают огромные возможности. Кстати, в приведенной Вами книге БПФ начинает обсуждаться только со стр.90, а не 39...42. И там уже попыток реализации БПФ на операционных усилителях не делается! :rolleyes:

Очень часто это так, но есть и исключения. Например, цифрового эквивалента аналогового фильтра на переключающихся конденсаторах я не знаю. А также аналоговых реализаций быстрых цифровых алгоритмов тоже нет. Например, БПФ и т.п. Это специфические алгоритмы именно для цифровой обработки! Что же касается АРУ, то при точностных возможностях современных АЦП (можно получить большой динамический диапазон уже в приемлемой для алгоритма разрядности), не факт что всегда предварительное аналоговое усиление и его автоматическая регулировка является хорошим выбором. Все зависит от схемотехники и устойчивости алгоритмов. Так почему же она (задача) еще не решена даже для таких брендов как Nokia и т.п.? У них то ресурсов (денег, мозгов и т.п. хватает). Ведь это было бы их небольшое но конкурентное преимущество. Но почему-то 99% всех GSM модулей имеют только команды для генерации DTMF, но не декодирования! Скорее всего не возможно обеспечить 100% работоспособность этого DTMF-декодера во всем спектре применений и условий эксплуатации GSM-модулей. А это уже не их (больших фирм) подход...