Не сложно. Если другая сторона перед смертью объявила размер окна равным скажем 64К, то эти 64К как раз и есть та дыра.

А как же "SEND OK", кто нам даст TCP ACK?

А никто - вывалится по таймауту. Я такое даже на обычных 3G свистках наблюдал на Водафоне.
Сижу в инете - пока шастаю по сайтам - все нормально.
Пошел попить чайку, прихожу - все, приехали любой запрос с браузера как бы уходит, но браузер ждет до посинения ответа.
Реконект - все опять работает. Поставил скрипт пинговать раз в минуту - перестало зависать.

Никто. Почитайте как работает TCP-сокет.
Любая из сторон TCP-сокета может передавать данные не дожидаясь подтверждений ранее переданного в пределах окна, которое было объявлено в последнем сообщении от 2-й стороны TCP-сокета.

А причем тут TCP сокет?
Речь о TCP стеке МОДЕМА, причем конкретного производителя. Предлагаю обсуждать его а не какого-то сферического коня в нонэйм 3Г свистке.
Выдержка из "AN_SIM900_TCPIP_V1.02"

Я лично понимаю так, что окно может быь любым, но SEND OK я получу только тогда, когда на все отправленные пакеты получу ACK.

Не всегда.

Например тут SEND OK не будет (SIM800 Series_TCPIP_Application Note_V1.01)

When command AT+CIPQSEND=1, it is in quick sending mode.
When the data is input to the serial port of module by AT+CIPSEND, it will respond DATA ACCEPT, while not respond SEND OK.
In such case, user can continuously use AT+CIPSEND to send data to the server.

Т.е. если это соединение Модем <-> Сервер, то размер для окна пакетов модема назначает сервер?

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

При том что мой ответ был на Вашу конкретную фразу о TCP вообще. И фраза ваша была о TCP вообще, а не о каком-то модеме.


У TCP нет понятия "модем". Есть понятие "клиент" (тот кто инициировал открытие сокета) и есть "сервер" (тот кто принял запрос открытия сокета).
И размеры окон назначают обе стороны независимо, каждая - в свою сторону.


Он должен его (размер окна) запросить у клиента (того, кто послал модему команду открытия соединения). Или, если такого в API нет, то думаю - неявно принять равным размеру внутреннего приёмного буфера сокета в модеме. Обычно это размер некоего буфера.


Нет, всё не так. TCP ack - это одно, а окно - другое. С ack-ом приходит новый размер окна. Пока он не пришёл - можно слать не более чем было указано в последнем ack-е.
Ack приходит всегда (если данные корректно приняты), но с задержкой. Приёмная сторона, приняв порцию данных, может её не сразу подтвердить, а через некоторое время. Это для сокращения пустого траффика.
Если же отправитель, будет отправлять данные малыми порциями и после каждой такой порции ждать ack (как делают многие криворукие программёры), то передача будет очень медленной.
Это всё описано в описании TCP-протокола.

Спасибо за разъяснения. Все никак не могу добраться до изучения RFC
Сдается мне, что это и реализованно в стандартном режиме посылки данных по TCP, поэтому у всех и получается всего 1-2 кбайта/сек

Там сейчас добавлен еще один режим передачи, AT+CIPQSEND=1 (quick sending mode),
вот я его как раз хочу попробовать.


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

HW/SW flow control, см. AT+IFC

Если примерно знать протокол TCP, можно использовать Wireshark все становится ясно, кто в чем виноват. Протестировал SIM800c, работает корректно. Как было сказано, есть операторы, которые перестают обслуживать GPRS канал после определенного времени простоя и никаких признаков не подают, мертвый канал определяет противоположная сторона несколькими попытками ретрансмита. Лечится это PING'ом, но я использую keepalive (SIM800 имеет настройку - 1 команда и проблем нет).