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