Тогда тебе придётся свой стек городить !!! А это опять же на порядок сложнее чем написать свой сервак на высокоуровневом языке!!!

Да. Видимо придется все-таки переплачивать за трафик.

Напиши в С++ сервачок сокетный c доступом к БД. И смени хостера на того который даст тебе условия для его запуска. Это мне кажется даже надёжней чем кидать данные в GET или POST.

Тут уже скорее всего придется ставить свой физический сервер в дата-центре, либо арендовать выделенный. К этому я пока не готов.
В принципе нашел недорогой пакет интернета на Life. Пока буду работать с HTTP.
Спасибо за помощь!

Сообщение отредактировал Alt.F4 - May 1 2011, 17:37

Ямщик не гони... ты гониш ямщик...





)) Сори за офф )) Даздраперма

Вопрос с блокировкой 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 перед TCP высказанные в паре слов, даже если краткость и сестра таланта никакого доверия вызвать не могут.
TCP родился как метод надежной работы через медленные и глючные модемные каналы. Лучше чем TCP данные через такие каналы никто не передаст.
Сколько бы вы не изощрялись с повышением надежности при использовании UDP вы в конечном счете придете к идеям реализованным в TCP.





Ну теперь представим что эти 260 клиентов юзают движки на PHP которые отсылают емайлы, сканируют фиды, лазят по соц. сетям, держат магазины и т.д. Т.е. каждый в секунду делает по 10-100 DNS запросов в среднем.
Итого только от этого у вас все время занято 26 тыс. UDP портов! на одном IP адресе.
Далее, применение NAT сразу ставит проблему определения номера публичного UDP порта, он будет не такой какой вы открыли на сервере.
И наконец хостеры с учетом большого трафика на UDP порты могут изменить политику их удержания, т.е. открытый UDP может удерживаться значительно короче чем обычно, и тогда необходим будет лишний трафик для поддержания такого канала открытым.

Познавательно!

Так разве на айпи модема ответ не прилетит, если мы и закроем соединение до его прихода?

"Прилетит" на оборудование оператора, но не будет модулем подтвержден, а значит и тарифицирован.
Но эта гипотеза требует проверки




Если цель одна - надежность доставки,то преимущества TCP очевидны!
А чтобы не получать ответы Web-сервера (а именно они больше всего волнуют автора топика) можно порекомендовать использовать не связку HTTP-TCP, а только TCP-сокеты.
Кроме того, на нем легче осуществить идентификацию отправителя.

Для UDP есть свои ниши. Недаром он не умер в процессе эволюции.
На нем достигается многоадресная рассылка, быстрота передачи - нет периода установления соединения, минимум трафика, например.
Есть масса приложений в которых TCP не имеет преимуществ.
Например потоковое аудио и видео. Часто Вы видите/слышите сбой при приеме мультимедиа on-line? Если бы там было 5-10% потерь пакетов, уже слушать/смотреть нельзя было бы! А объем-то передан какой! Не то что в текущей задаче
Или классический пример - служба времени.
В любом из этих случаев повторять утерянные пакеты бессмысленно.
Кстати, для службы DNS не менее важна надежность, но она обычно функционирует на UDP. А перевести ее админу на TCP не тривиальная задача!

А автор топика написал: "...Это было бы идеальным вариантом ....А уверенность о доставке мне не нужна... пока...."

После того как Вам удалось зарегистрировать и привязать серверный сокет - порт уже Ваш и демон будет вызывать именно Ваш скрипт. Так что другие порты уже не должны волновать.

Не совсем понятно назначение NAT для сервера ЦОД? Как тогда до него "достучаться"? Поясните пожалуйста.
Если речь идет про клиентов запускающихся по cron (или иначе) на сервере и внутреннюю инфраструктуру ЦОД, то они нас разве волнуют?

Сейчас провел эксперимент.
Для клиента (в смысле архитектура "клиент-сервер") на хостинге действуй PAT. А IP-адрес не меняется даже для него.

Чесно говоря я серьезно даже не пытаюсь анализировать почему автор решил, что ему ответ сервера не нужен. Это выглядит абсурдно с учетом того, что в мобильной сети может теряться добрая половина пакетов. Экономить трафик можно и другими путями не менее эффективными.

Обсуждать UDP vs TCP тут тоже как-то не в тему. Я сам разрабытываю телеметрические дивайсы с SNMP который работает по UDP, также делаю дивайсы с L2TP тоннелем тоже работающим по UDP. И отлично знаю трудоемкость реализации этих механизмов. Трудоемкость для TC я чувствую будет неадекватной.
Не отрицаю, что для достаточно редкой пересылки данных помещающихся в один пакет (сценарий работы DNS) можно использовать и UDP,но юзабельность такого канала связи будет копеечная, а реализуемось на стороннем хосте еще никто тут не продемонстрировал.

А зачем? У меня этот сервис уже порушен за ненадобностью. Поднимать его снова? Для чего? Что бы кому то, что то доказать? А зачем? И так по кругу...

NТо что предназначено Вам и прилетит на Оператора. будет тарифицировано в любом случае... у мну был прецедент. ответили просто и логично. мыже не знаем запрошеный это трафик или нет ))) но у мну был прямой "белый" айпи.

Элементарно. Из GET запроса исключи HTTP/1.1 и в ответ нмчего не получиш. При этом данные проходят нормально. Проверено.

Это вряд ли, Google на такой финт целую петицию присылает с извинениями, что такая страница перемещена.
Вообще для игры с HTTP запросами очень удобна програмка Fiddler WEB debugger.