| |
 Возможно ли отключить входящий трафик при TCP соединении по GPRS? |
|
|
|
|
 Apr 25 2011, 17:34
|
Профессионал
Группа: Свой
Сообщений: 1 468
Регистрация: 28-03-10
Из: Беларусь
Пользователь №: 56 256
|
Цитата Да, со стороны сервера не отправлять. А это возможно? Если да, то как? (сервер хостера) По идее HTTP построен на двусторонней работе ("клиент сервер"). Вот бы по UDP научиться принимать на стороне сервера... 
Сообщение отредактировал Alt.F4 - Apr 25 2011, 17:35
|
|
|
|
|
|
|
|
Apr 25 2011, 17:56
|
Профессионал
Группа: Свой
Сообщений: 1 468
Регистрация: 28-03-10
Из: Беларусь
Пользователь №: 56 256
|
Цитата Соединяйся с БД напрямую. Я в БД пишу еще время и дату + некоторая конвертация полученных данных (на PHP), поэтому отпадает. Цитата Или напиши сервер TCPшный А вот это для меня очень круто (на чем писать, как писать...) Добавлено:Шукаю возможность чтения UDP с помощью PHP - нашел функции socket, но для них требуется айпи, что опять не подходит. Использовать dyndns нет желания.
Сообщение отредактировал Alt.F4 - Apr 25 2011, 18:43
|
|
|
|
|
|
|
|
Apr 25 2011, 19:03
|
Профессионал
Группа: Свой
Сообщений: 1 468
Регистрация: 28-03-10
Из: Беларусь
Пользователь №: 56 256
|
Цитата Да в чём угодно, Qt4 хотябы (отличная вещь), готовые библиотеки, сокетами накидал сервак,обвешал обработчиком подключил библиотеки SQL и закинул в туже БД. "Cервак" - это программа типа Apache?. Отпадает, хостер не разрешит поставить. Или Вы имеете ввиду написанную прогу-сервак залить в БД? Я пока далек от этого. Мне было бы проще все обработать на PHP.
Сообщение отредактировал Alt.F4 - Apr 25 2011, 19:06
|
|
|
|
|
|
|
|
Apr 26 2011, 04:05
|
Профессионал
Группа: Свой
Сообщений: 1 468
Регистрация: 28-03-10
Из: Беларусь
Пользователь №: 56 256
|
Цитата Можно, конечно. Отправляйте данные сразу с флагом сброса подключения в хидере TCP. И больше вам никто ничего не пошлет. А что это за флаг? Это добавить строку "Connection: close"? Вечером попробую, надо убегать на стройку батрачить. Цитата Пример сервера и клиента А кто на модеме обработает PHP скрипт? 
|
|
|
|
|
|
|
|
Apr 26 2011, 09:09
|
Местный
Группа: Участник
Сообщений: 212
Регистрация: 2-02-11
Пользователь №: 62 643
|
Цитата(av-master @ Apr 26 2011, 08:53)  vps - от 10у.е. / мес . что хочешь делай. http://budgetdedicated.com - ~$20-30/month Но я таки тоже посоветую этот вариант. Сервер на php, на вебхостинге -- это сколько-нибудь массово и надёжно не работает. Сервер писать на C или perl. На php тоже можно, но плохо. Лучше на C. И не факт, что нужна реляционная субд. Скорей достаточно berkeleydb. Лучше, быстрей, надёжней. И, возможно, UDP лучше. TCP в общем случае не гарантирует доставку... и какой-то ответ получать надо (туда пакеты ушли, обратно нифига -- а как понять, что они дошли? таймаут по-дефолту пол-дня ждёт если не больше)
Сообщение отредактировал Frolov Kirill - Apr 26 2011, 09:11
|
|
|
|
|
|
|
|
Apr 28 2011, 01:50
|
Местный
Группа: Свой
Сообщений: 202
Регистрация: 18-05-09
Из: Novosibirsk
Пользователь №: 49 204
|
Цитата(Alt.F4 @ Apr 25 2011, 20:06) Добрый день.
Соединяюсь с сервером по TCP и передаю GET'ом несколько переменных, в ответ сервер шлет отклик в два раза больший по размеру.
Можно ли как-то на модеме отключить входящий трафик?
Спасибо. Вы бы уточнили про какой размер трафика запроса/ответа идет речь! Чтобы можно было понять чей это ответ - TCP или Web-сервера или серверного скрипта Сервер и скрипт Ваши? Что он отвечает точно понятно? Или это чужая реализация? Если Вы хотите чтобы входящего трафика с сервера не было вообще - транспорт TCP не подойдет. Т.к. он по определению подразумевает обмен и наклодные затраты - синхронизация, квитирование, повтор при потере ... Сброс флага RST в заголовке TCP не подойдет (даже если бы у Вас был внешний стек), т.к. не угодать с моментом его установки! Он должен установлен и отослан уже после получения запроса Web-сервером и скриптом, но до ответа! Что не реально! Прямое подключение к сетевой СУБД MySQL- тоже не спасет, т.к. используется транспорт TCP тоже. Если необходимо минимизировать трафик, и в частности входящий от ответа сервера - используйте UDP. Но платой за это является отсутствие уверенности о доставке Ваших данных! Впрочем, что-то простое здесь можно и самому предложить в зависимости от ТЗ. Совсем уж доводить до нескольких сотен байт мобильный трафик вряд ли уместно, т.к. существует округление в большую сторону у операторов. Если же Вы расчитываете использовать нетарифицируемый интервал (есть на некоторых тарифах ~ <2кб), то тоже сомнительно. Как я ранее описывал на форуме такую ситуацию у меня - оператор просто заблокировал не несколько недель целевой IP. Правды у него (GSM-оператора) добиться не удалось. И мне пришлость использовать proxy. Но трафик уже был болеее 2кб. А значит округлялся до 100 кб 
|
|
|
|
|
|
|
|
Apr 28 2011, 04:25
|
Профессионал
Группа: Свой
Сообщений: 1 468
Регистрация: 28-03-10
Из: Беларусь
Пользователь №: 56 256
|
Цитата Вы бы уточнили про какой размер трафика запроса/ответа идет речь! Собираюсь отправлять 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.
Но платой за это является отсутствие уверенности о доставке Ваших данных! Это было бы идеальным вариантом, но я не знаю как обработать полученные данные по UDP на сервере. А уверенность о доставке мне не нужна... пока. Цитата Совсем уж доводить до нескольких сотен байт мобильный трафик вряд ли уместно, т.к. существует округление в большую сторону у операторов. У нас МТС до 50кбайт округляет. Но все равно из-за ответов сервера, я прикинул, за час работы набежит примерно 0,5$.
Сообщение отредактировал Alt.F4 - Apr 28 2011, 04:27
|
|
|
|
|
|
|
|
Apr 29 2011, 00:45
|
Местный
Группа: Свой
Сообщений: 202
Регистрация: 18-05-09
Из: Novosibirsk
Пользователь №: 49 204
|
Цитата(Alt.F4 @ Apr 28 2011, 07:25) ...
Это было бы идеальным вариантом, но я не знаю как обработать полученные данные по UDP на сервере. Про реализации и особенности UDP-сервера можно познакомиться например в кн. "Разработка сетевых программ на Perl" Но все это возможно и на PHP.
|
|
|
|
|
|
|
|
Apr 29 2011, 10:24
|
Участник
Группа: Участник
Сообщений: 46
Регистрация: 1-11-06
Пользователь №: 21 854
|
Ребята уже предлагали, но повторюсь. Если сервер ваш, то зачем использовать текстовый протокол HTTP? Откройте сокет и шлите данные какие вам угодно и ответ формируйте также какой нужен. обычный обмен данными через TCP. входящий траффик не возьмется ни откуда. На том же Builder или Delphi есть готовые неплохие компоненты работы с сокетом.
Сообщение отредактировал Roman_V - Apr 29 2011, 10:26
|
|
|
|
|
|
|
|
Apr 30 2011, 09:54
|
Профессионал
Группа: Свой
Сообщений: 1 468
Регистрация: 28-03-10
Из: Беларусь
Пользователь №: 56 256
|
alx125, полистал рекомендованную Вами книгу. Но вот как все это дело развернуть на PHP, ума не приложу. Пробовал использовать пример с оф.сайта PHP. Взял порт 80, у хостера почти все закрыты: Код <?php
$socket = stream_socket_server("udp://91.149.145.36:80", $errno, $errstr, STREAM_SERVER_BIND);
if (!$socket) {
die("$errstr ($errno)");
}
do {
$pkt = stream_socket_recvfrom($socket, 1, 0, $peer);
echo "$peer\n";
stream_socket_sendto($socket, date("D M j H:i:s Y\r\n"), 0, $peer);
} while ($pkt !== false);
//и пишу в БД "$pkt"
?> Пробую передавать данные через терминалку " Hercules" (поддерживает UDP соединение). Но в результате ничего не приходит в ответ и в БД пусто... Подскажите пожалуйста, где ошибка. Спасибо. з.ы. видимо в строку udp://91.149.145.36:80 необходимо писать айпи клиента? Я написал сервера, считая что PHP будет просто слушать порт.
Сообщение отредактировал Alt.F4 - Apr 30 2011, 09:57
|
|
|
|
|
|
|
|
May 1 2011, 02:49
|
Профессионал
Группа: Свой
Сообщений: 1 468
Регистрация: 28-03-10
Из: Беларусь
Пользователь №: 56 256
|
Цитата У вас реально один путь, как я сказал, это управлять непосредственно содержимым заголовков TCP пакетов исходящих от вас. А как, в таком случае, на модеме можно открыть сессию TCP без использования встроенного стека? Спасибо.
|
|
|
|
|
|
|
|
May 1 2011, 17:37
|
Профессионал
Группа: Свой
Сообщений: 1 468
Регистрация: 28-03-10
Из: Беларусь
Пользователь №: 56 256
|
Цитата Напиши в С++ сервачок сокетный c доступом к БД. И смени хостера на того который даст тебе условия для его запуска. Это мне кажется даже надёжней чем кидать данные в GET или POST. Тут уже скорее всего придется ставить свой физический сервер в дата-центре, либо арендовать выделенный. К этому я пока не готов. В принципе нашел недорогой пакет интернета на Life. Пока буду работать с HTTP. Спасибо за помощь!
Сообщение отредактировал Alt.F4 - May 1 2011, 17:37
|
|
|
|
|
|
|
|
May 3 2011, 23:27
|
Местный
Группа: Свой
Сообщений: 202
Регистрация: 18-05-09
Из: Novosibirsk
Пользователь №: 49 204
|
Вопрос с блокировкой 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-стека модуля наверняка работает в отдельном потоке и не предсказуема.
Конечно это только гипотеза требующая проверки на реальной реализации.
|
|
|
|
|
|
|
|
May 4 2011, 05:48
|
Ally
Группа: Модераторы
Сообщений: 6 232
Регистрация: 19-01-05
Пользователь №: 2 050
|
Цитата(alx125 @ May 4 2011, 02:27) Но лучше подойдет для этого виртуальный сервер, где ширина канала (нагрузка на CPU в данном случае не важна) гарантирована. Чуть дороже зато решит Ваши задачи с UDP-сокетами.
Для Вашего случая он может даже самоокупиться по сравнению с использованием TCP-HTTP протоколов. Понимаете, все рассуждения о преимуществе UDP перед TCP высказанные в паре слов, даже если краткость и сестра таланта никакого доверия вызвать не могут. TCP родился как метод надежной работы через медленные и глючные модемные каналы. Лучше чем TCP данные через такие каналы никто не передаст. Сколько бы вы не изощрялись с повышением надежности при использовании UDP вы в конечном счете придете к идеям реализованным в TCP. Цитата(alx125 @ May 4 2011, 02:27) По поводу нехватки портов в системе.
Как известно их >60тысяч для UDP и столько же для TCP ("Хорошо известные" и доп. я грубо вычел)
В случае виртуального хостинга на одном IP-адресе находится от нескольких десятков до несколько сотен сайтов (у меня это - 260 шт)
Так что свободных портов (особенно UDP) "завались" по определению.
А если у сервера несколько IP - то и больше.
Есть только такой момент - если порт выделен операционной системой по запросу, из скрипта вернуть его в пул системы не получится. Ну теперь представим что эти 260 клиентов юзают движки на PHP которые отсылают емайлы, сканируют фиды, лазят по соц. сетям, держат магазины и т.д. Т.е. каждый в секунду делает по 10-100 DNS запросов в среднем. Итого только от этого у вас все время занято 26 тыс. UDP портов! на одном IP адресе. Далее, применение NAT сразу ставит проблему определения номера публичного UDP порта, он будет не такой какой вы открыли на сервере. И наконец хостеры с учетом большого трафика на UDP порты могут изменить политику их удержания, т.е. открытый UDP может удерживаться значительно короче чем обычно, и тогда необходим будет лишний трафик для поддержания такого канала открытым.
|
|
|
|
|
|
|
|
May 5 2011, 15:31
|
Профессионал
Группа: Свой
Сообщений: 1 468
Регистрация: 28-03-10
Из: Беларусь
Пользователь №: 56 256
|
Познавательно! Цитата Есть еще несколько соображений как получить подходящий результат простыми средствами.
Попытаться использовать AT-команды (я рассматриваю SimCom):
Вариант 1). AT+CIPCLOSE - закрыть TCP соединение ч/з некоторое время после отправки запроса. При этом PDP контекст остается активен и не начнется новый период тарификации!
Вариант 2). AT+CLPORT - сменить порт ч/з некоторое время после отправки TCP-запроса. Ответ Web-сервера поступит, но не будет подтвержден модулем, а значит не будет и тарифицирован. Так разве на айпи модема ответ не прилетит, если мы и закроем соединение до его прихода?
|
|
|
|
|
|
|
|
May 5 2011, 23:13
|
Местный
Группа: Свой
Сообщений: 202
Регистрация: 18-05-09
Из: Novosibirsk
Пользователь №: 49 204
|
Цитата(Alt.F4 @ May 5 2011, 19:31) Познавательно!
Так разве на айпи модема ответ не прилетит, если мы и закроем соединение до его прихода? "Прилетит" на оборудование оператора, но не будет модулем подтвержден, а значит и тарифицирован. Но эта гипотеза требует проверки Цитата(AlexandrY @ May 4 2011, 09:48) Понимаете, все рассуждения о преимуществе UDP перед TCP высказанные в паре слов, даже если краткость и сестра таланта никакого доверия вызвать не могут.....
Ну теперь представим что эти 260 клиентов юзают движки на PHP которые отсылают емайлы, сканируют фиды, лазят по соц. сетям, держат магазины и т.д. Т.е. каждый в секунду делает по 10-100 DNS запросов в среднем.
Итого только от этого у вас все время занято 26 тыс. UDP портов! на одном IP адресе. Если цель одна - надежность доставки,то преимущества TCP очевидны! А чтобы не получать ответы Web-сервера (а именно они больше всего волнуют автора топика) можно порекомендовать использовать не связку HTTP-TCP, а только TCP-сокеты. Кроме того, на нем легче осуществить идентификацию отправителя. Для UDP есть свои ниши. Недаром он не умер в процессе эволюции. На нем достигается многоадресная рассылка, быстрота передачи - нет периода установления соединения, минимум трафика, например. Есть масса приложений в которых TCP не имеет преимуществ. Например потоковое аудио и видео. Часто Вы видите/слышите сбой при приеме мультимедиа on-line? Если бы там было 5-10% потерь пакетов, уже слушать/смотреть нельзя было бы! А объем-то передан какой! Не то что в текущей задаче Или классический пример - служба времени. В любом из этих случаев повторять утерянные пакеты бессмысленно. Кстати, для службы DNS не менее важна надежность, но она обычно функционирует на UDP. А перевести ее админу на TCP не тривиальная задача! А автор топика написал: " ...Это было бы идеальным вариантом ....А уверенность о доставке мне не нужна... пока...." После того как Вам удалось зарегистрировать и привязать серверный сокет - порт уже Ваш и демон будет вызывать именно Ваш скрипт. Так что другие порты уже не должны волновать. Не совсем понятно назначение NAT для сервера ЦОД? Как тогда до него "достучаться"? Поясните пожалуйста. Если речь идет про клиентов запускающихся по cron (или иначе) на сервере и внутреннюю инфраструктуру ЦОД, то они нас разве волнуют? Сейчас провел эксперимент. Для клиента (в смысле архитектура "клиент-сервер") на хостинге действуй PAT. А IP-адрес не меняется даже для него.
|
|
|
|
|
|
|
|
May 6 2011, 05:36
|
Ally
Группа: Модераторы
Сообщений: 6 232
Регистрация: 19-01-05
Пользователь №: 2 050
|
Цитата(alx125 @ May 6 2011, 02:13) Если цель одна - надежность доставки,то преимущества TCP очевидны!
..А чтобы не получать ответы Web-сервера (а именно они больше всего волнуют автора топика) можно порекомендовать использовать не связку HTTP-TCP, а только TCP-сокеты...
...Для UDP есть свои ниши. Недаром он не умер в процессе эволюции...
Сейчас провел эксперимент.
Для клиента (в смысле архитектура "клиент-сервер") на хостинге действуй PAT. А IP-адрес не меняется даже для него. Чесно говоря я серьезно даже не пытаюсь анализировать почему автор решил, что ему ответ сервера не нужен. Это выглядит абсурдно с учетом того, что в мобильной сети может теряться добрая половина пакетов. Экономить трафик можно и другими путями не менее эффективными. Обсуждать UDP vs TCP тут тоже как-то не в тему. Я сам разрабытываю телеметрические дивайсы с SNMP который работает по UDP, также делаю дивайсы с L2TP тоннелем тоже работающим по UDP. И отлично знаю трудоемкость реализации этих механизмов. Трудоемкость для TC я чувствую будет неадекватной. Не отрицаю, что для достаточно редкой пересылки данных помещающихся в один пакет (сценарий работы DNS) можно использовать и UDP,но юзабельность такого канала связи будет копеечная, а реализуемось на стороннем хосте еще никто тут не продемонстрировал.
|
|
|
|
|
|
|
|
May 10 2011, 13:02
|
Участник
Группа: Участник
Сообщений: 51
Регистрация: 8-01-07
Из: Одесса
Пользователь №: 24 196
|
Цитата(Alt.F4 @ Apr 25 2011, 20:06) Добрый день.
Соединяюсь с сервером по TCP и передаю GET'ом несколько переменных, в ответ сервер шлет отклик в два раза больший по размеру.
Можно ли как-то на модеме отключить входящий трафик?
Спасибо. Элементарно. Из GET запроса исключи HTTP/1.1 и в ответ нмчего не получиш. При этом данные проходят нормально. Проверено.
--------------------
Опыт - это та чудесная штука, которая позволяет вам узнать ошибку, когда вы ее повторите.
|
|
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|
Эта лабуда работать не будет у нормального хостера. 
