[jcxz 184]

В TCP вроде как сложно провернуть такое при отсутствии канала от модема до БС...

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

[Alechek 0]

64К как раз и есть та дыра. ;)

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

[CADiLO 9]

А никто - вывалится по таймауту. Я такое даже на обычных 3G свистках наблюдал на Водафоне.

Сижу в инете - пока шастаю по сайтам - все нормально.

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

Реконект - все опять работает. Поставил скрипт пинговать раз в минуту - перестало зависать.

 

[jcxz 184]

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

Никто. Почитайте как работает TCP-сокет.

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

[Alechek 0]

А причем тут TCP сокет?

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

Выдержка из "AN_SIM900_TCPIP_V1.02"

Note [3]: For TCP, “SEND OK” means data has been sent out and received successfully by the

remote server, due to the TCP connection-oriented protocol; for UDP, “SEND OK” just

means data has been sent out from the serial port of module, not meaning data reaching

the server, due to the UDP simpler message-based connectionless protocol.

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

 

[CADiLO 9]

Не всегда.

 

Например тут 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.

 

 

[Baser 5]

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

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

 

А какой размер окна у стека модема на прием? Судя по отсутствию настроек и логики работы,

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

Правильно?

[jcxz 184]

А причем тут TCP сокет?

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

 

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

У TCP нет понятия "модем". Есть понятие "клиент" (тот кто инициировал открытие сокета) и есть "сервер" (тот кто принял запрос открытия сокета).

И размеры окон назначают обе стороны независимо, каждая - в свою сторону.

 

А какой размер окна у стека модема на прием? Судя по отсутствию настроек и логики работы,

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

 

Сколько бы сервер ни прислал данных, модем обычно тут-же подтверждает.

Нет, всё не так. TCP ack - это одно, а окно - другое. С ack-ом приходит новый размер окна. Пока он не пришёл - можно слать не более чем было указано в последнем ack-е.

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

Если же отправитель, будет отправлять данные малыми порциями и после каждой такой порции ждать ack (как делают многие криворукие программёры), то передача будет очень медленной.

Это всё описано в описании TCP-протокола.

[Baser 5]

Нет, всё не так. TCP ack - это одно, а окно - другое. С ack-ом приходит новый размер окна. Пока он не пришёл - можно слать не более чем было указано в последнем ack-е.

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

Если же отправитель, будет отправлять данные малыми порциями и после каждой такой порции ждать ack (как делают многие криворукие программёры), то передача будет очень медленной.

Это всё описано в описании TCP-протокола.

Спасибо за разъяснения. Все никак не могу добраться до изучения RFC :)

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

 

Там сейчас добавлен еще один режим передачи, AT+CIPQSEND=1 (quick sending mode),

вот я его как раз хочу попробовать.

 

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.

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

Как можно узнать что заполнен приемный буфер и модем больше не может принимать данные?

 

[batuev.b 0]

Как можно узнать что заполнен приемный буфер и модем больше не может принимать данные?

 

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

[wild.hamster 0]

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