Добрый день.
Соединяюсь с сервером по TCP и передаю GET'ом несколько переменных, в ответ сервер шлет отклик в два раза больший по размеру.
Можно ли как-то на модеме отключить входящий трафик?
Спасибо.

Да, со стороны сервера не отправлять.
ЗЫ. Ну сам прикинь, что оператору делать с тем ответом который по твоему GET-у прислал сервер... Или думаешь оператор свои деньги не умеет считать?

А это возможно? Если да, то как? (сервер хостера)
По идее HTTP построен на двусторонней работе ("клиент сервер").
Вот бы по UDP научиться принимать на стороне сервера...

Соединяйся с БД напрямую. Или напиши сервер TCPшный, который будет закидывать данные в БД.

Я в БД пишу еще время и дату + некоторая конвертация полученных данных (на PHP), поэтому отпадает.
А вот это для меня очень круто (на чем писать, как писать...)

Добавлено:
Шукаю возможность чтения UDP с помощью PHP - нашел функции socket, но для них требуется айпи, что опять не подходит. Использовать dyndns нет желания.

Да в чём угодно, Qt4 хотябы (отличная вещь), готовые библиотеки, сокетами накидал сервак,обвешал обработчиком подключил библиотеки SQL и закинул в туже БД.

"Cервак" - это программа типа Apache?. Отпадает, хостер не разрешит поставить.
Или Вы имеете ввиду написанную прогу-сервак залить в БД? Я пока далек от этого.
Мне было бы проще все обработать на PHP.

2 вариант , но с заливкой в БД мне кажется нереально. Хотя PostgreSQL например - открытый код.

Можно, конечно. Отправляйте данные сразу с флагом сброса подключения в хидере TCP. И больше вам никто ничего не пошлет.

Пример сервера и клиента

А что это за флаг? Это добавить строку "Connection: close"?
Вечером попробую, надо убегать на стройку батрачить.
А кто на модеме обработает PHP скрипт?

Опять шутка, опять удачная... Вам же посоветовали - сделать на стороне сервера TCP сервер, как сделать? Ссылку я дал.

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

У меня хост на Majordomo.ru проблем нет, правда я и нагрузку большую не давал, девайсов 20-30.

vps - от 10у.е. / мес . что хочешь делай.

Если комерческий проЕкт то можно и бабла отвалить хостеру за уменьшеный трафик. Если для себя или протестить - купить внешний айпи и запустить у себя на компе. К примеру у нас в Украине внешний айпи стоит 48грн (6$) + пакет инета ещё столько же (UKRTEL). Или базу данных и оболочку запустить на хостере, а сервер и обработчик запустить у себя.

Ну-ну, прямо нет, их не может не быть с таким скриптом. Хостеры держат всю эту лабуду как минимум за NAT-ом.
Дайте прямой IP и порт на такой сервер у Majordomo.ru, тогда поверю.

http://budgetdedicated.com - ~$20-30/month

Но я таки тоже посоветую этот вариант. Сервер на php, на вебхостинге -- это сколько-нибудь массово и надёжно не работает. Сервер писать на C или perl. На php тоже можно, но плохо. Лучше на C. И не факт, что нужна реляционная субд. Скорей достаточно berkeleydb. Лучше, быстрей, надёжней.

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

Проект для себя. Сервер писать пока не готов.
AlexandrY, я так понимаю заголовок TCP генерирует сам модем, тогда как мне установить флаг сброса соединения RST?
Спасибо.

Если вы используете встроенный TCP/IP то честно говоря не знаю.

Видимо надо остановиться на этом варианте.
Подглядеть бы где рабочий листинг команд соединения с MySQL...

Вы бы уточнили про какой размер трафика запроса/ответа идет речь!
Чтобы можно было понять чей это ответ - TCP или Web-сервера или серверного скрипта
Сервер и скрипт Ваши? Что он отвечает точно понятно? Или это чужая реализация?

Если Вы хотите чтобы входящего трафика с сервера не было вообще - транспорт TCP не подойдет.
Т.к. он по определению подразумевает обмен и наклодные затраты - синхронизация, квитирование, повтор при потере ...
Сброс флага RST в заголовке TCP не подойдет (даже если бы у Вас был внешний стек), т.к. не угодать с моментом его установки!
Он должен установлен и отослан уже после получения запроса Web-сервером и скриптом, но до ответа! Что не реально!

Прямое подключение к сетевой СУБД MySQL- тоже не спасет, т.к. используется транспорт TCP тоже.

Если необходимо минимизировать трафик, и в частности входящий от ответа сервера - используйте UDP.
Но платой за это является отсутствие уверенности о доставке Ваших данных!
Впрочем, что-то простое здесь можно и самому предложить в зависимости от ТЗ.

Совсем уж доводить до нескольких сотен байт мобильный трафик вряд ли уместно, т.к. существует округление в большую сторону у операторов.
Если же Вы расчитываете использовать нетарифицируемый интервал (есть на некоторых тарифах ~ <2кб), то тоже сомнительно.
Как я ранее описывал на форуме такую ситуацию у меня - оператор просто заблокировал не несколько недель целевой IP.
Правды у него (GSM-оператора) добиться не удалось.
И мне пришлость использовать proxy. Но трафик уже был болеее 2кб. А значит округлялся до 100 кб

Собираюсь отправлять 80байт/с (это без заголовков TCP), и на каждый запрос, сервер будет отвечать:
HTTP/1.1 200 OK
Date: Sat, 23 Apr 2011 20:31:22 GMT
Server: Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny8 with Suhosin-Patch mod_ssl/2.2.9 OpenSSL/0.9.8g mod_perl/2.0.4 Perl/v5.10.0
X-Powered-By: PHP/5.2.6-1+lenny8
Vary: Accept-Encoding
Content-Length: 0
Content-Type: text/html
Сервер хостера, скрипт мой. В принципе понятно, HTTP так устроен, на запрос-ответе...

Это было бы идеальным вариантом, но я не знаю как обработать полученные данные по UDP на сервере.
А уверенность о доставке мне не нужна... пока.
У нас МТС до 50кбайт округляет.
Но все равно из-за ответов сервера, я прикинул, за час работы набежит примерно 0,5$.

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

alx125, спасибо. На выходных ознакомлюсь с рекомендованной книгой.
Линкольн Д. Штайн "Разработка сетевых программ на Perl"

Ребята уже предлагали, но повторюсь. Если сервер ваш, то зачем использовать текстовый протокол HTTP? Откройте сокет и шлите данные какие вам угодно и ответ формируйте также какой нужен. обычный обмен данными через TCP. входящий траффик не возьмется ни откуда. На том же Builder или Delphi есть готовые неплохие компоненты работы с сокетом.

Сервер хостера.

alx125, полистал рекомендованную Вами книгу. Но вот как все это дело развернуть на PHP, ума не приложу.
Пробовал использовать пример с оф.сайта PHP. Взял порт 80, у хостера почти все закрыты:
Пробую передавать данные через терминалку "Hercules" (поддерживает UDP соединение).
Но в результате ничего не приходит в ответ и в БД пусто...
Подскажите пожалуйста, где ошибка.
Спасибо.
з.ы. видимо в строку udp://91.149.145.36:80 необходимо писать айпи клиента? Я написал сервера, считая что PHP будет просто слушать порт.

Ну я же предупреждал. Эта лабуда работать не будет у нормального хостера.
Потому как у них интернет идет через NAT-ы и файрволы. Порты надо открывать прежде всего на них, а уж потом на самом хосте.
Без хака сети првайдера тут не обойтись.

У вас реально один путь, как я сказал, это управлять непосредственно содержимым заголовков TCP пакетов исходящих от вас.

А как, в таком случае, на модеме можно открыть сессию TCP без использования встроенного стека?
Спасибо.

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

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

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

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

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





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

Вопрос с блокировкой 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.