Возможно ли отключить входящий трафик при TCP соединении по GPRS? Опции

[Alt.F4]

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

[alx125]

Вопрос с блокировкой 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-стека модуля наверняка работает в отдельном потоке и не предсказуема.
Конечно это только гипотеза требующая проверки на реальной реализации.

[AlexandrY]

Но лучше подойдет для этого виртуальный сервер, где ширина канала (нагрузка на CPU в данном случае не важна) гарантирована. Чуть дороже зато решит Ваши задачи с UDP-сокетами.
Для Вашего случая он может даже самоокупиться по сравнению с использованием TCP-HTTP протоколов.

Понимаете, все рассуждения о преимуществе UDP перед TCP высказанные в паре слов, даже если краткость и сестра таланта никакого доверия вызвать не могут.
TCP родился как метод надежной работы через медленные и глючные модемные каналы. Лучше чем TCP данные через такие каналы никто не передаст.
Сколько бы вы не изощрялись с повышением надежности при использовании UDP вы в конечном счете придете к идеям реализованным в TCP.

По поводу нехватки портов в системе.
Как известно их >60тысяч для UDP и столько же для TCP ("Хорошо известные" и доп. я грубо вычел)
В случае виртуального хостинга на одном IP-адресе находится от нескольких десятков до несколько сотен сайтов (у меня это - 260 шт)
Так что свободных портов (особенно UDP) "завались" по определению.
А если у сервера несколько IP - то и больше.
Есть только такой момент - если порт выделен операционной системой по запросу, из скрипта вернуть его в пул системы не получится.

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