Jump to content

    
Sign in to follow this  
Mysteo

Скорость передачи GPRS SIM800C

Recommended Posts

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

 

Share this post


Link to post
Share on other sites
А как же "SEND OK", кто нам даст TCP ACK?

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

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

Share this post


Link to post
Share on other sites

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

 

Share this post


Link to post
Share on other sites

Не всегда.

 

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

 

 

Share this post


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

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

 

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

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

Правильно?

Share this post


Link to post
Share on other sites
А причем тут TCP сокет?

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

 

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

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

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

 

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

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

 

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

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

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

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

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

Share this post


Link to post
Share on other sites
Нет, всё не так. 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.

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

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

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this