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

[Alt.F4]

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

[Alt.F4]

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

Есть еще несколько соображений как получить подходящий результат простыми средствами.
Попытаться использовать AT-команды (я рассматриваю SimCom):
Вариант 1). AT+CIPCLOSE - закрыть TCP соединение ч/з некоторое время после отправки запроса. При этом PDP контекст остается активен и не начнется новый период тарификации!
Вариант 2). AT+CLPORT - сменить порт ч/з некоторое время после отправки TCP-запроса. Ответ Web-сервера поступит, но не будет подтвержден модулем, а значит не будет и тарифицирован.

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

[alx125]

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

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

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

Понимаете, все рассуждения о преимуществе 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-адрес не меняется даже для него.

[AlexandrY]

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

...Для UDP есть свои ниши. Недаром он не умер в процессе эволюции...

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

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

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

[sobr]

...а реализуемось на стороннем хосте еще никто тут не продемонстрировал.

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