реклама на сайте
подробности

 
 
2 страниц V  < 1 2  
Reply to this topicStart new topic
> Скорость передачи GPRS SIM800C
jcxz
сообщение Jan 22 2018, 14:40
Сообщение #16


Гуру
******

Группа: Свой
Сообщений: 4 108
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713



Цитата(Alechek @ Jan 22 2018, 11:27) *
В TCP вроде как сложно провернуть такое при отсутствии канала от модема до БС...

Не сложно. Если другая сторона перед смертью объявила размер окна равным скажем 64К, то эти 64К как раз и есть та дыра. wink.gif
Go to the top of the page
 
+Quote Post
Alechek
сообщение Jan 24 2018, 08:40
Сообщение #17


Профессионал
*****

Группа: Свой
Сообщений: 1 223
Регистрация: 15-11-05
Из: Челябинск
Пользователь №: 10 882



Цитата(jcxz @ Jan 22 2018, 19:40) *
64К как раз и есть та дыра. wink.gif

А как же "SEND OK", кто нам даст TCP ACK?
Go to the top of the page
 
+Quote Post
CADiLO
сообщение Jan 24 2018, 09:32
Сообщение #18


Гуру
******

Группа: Свой
Сообщений: 5 912
Регистрация: 26-08-05
Из: Днепр
Пользователь №: 7 988



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


--------------------
Не можна втрачати надію. Не можна здаватися до останньої миті. Можливо саме вона, остання мить, принесе весну, яка стане початком нового життя.
Go to the top of the page
 
+Quote Post
jcxz
сообщение Jan 24 2018, 10:18
Сообщение #19


Гуру
******

Группа: Свой
Сообщений: 4 108
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713



Цитата(Alechek @ Jan 24 2018, 10:40) *
А как же "SEND OK", кто нам даст TCP ACK?

Никто. Почитайте как работает TCP-сокет.
Любая из сторон TCP-сокета может передавать данные не дожидаясь подтверждений ранее переданного в пределах окна, которое было объявлено в последнем сообщении от 2-й стороны TCP-сокета.
Go to the top of the page
 
+Quote Post
Alechek
сообщение Jan 24 2018, 11:26
Сообщение #20


Профессионал
*****

Группа: Свой
Сообщений: 1 223
Регистрация: 15-11-05
Из: Челябинск
Пользователь №: 10 882



Цитата(jcxz @ Jan 24 2018, 15:18) *

А причем тут 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.
Go to the top of the page
 
+Quote Post
CADiLO
сообщение Jan 24 2018, 12:10
Сообщение #21


Гуру
******

Группа: Свой
Сообщений: 5 912
Регистрация: 26-08-05
Из: Днепр
Пользователь №: 7 988



Не всегда.

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



--------------------
Не можна втрачати надію. Не можна здаватися до останньої миті. Можливо саме вона, остання мить, принесе весну, яка стане початком нового життя.
Go to the top of the page
 
+Quote Post
Baser
сообщение Jan 24 2018, 13:52
Сообщение #22


Просто Che
*****

Группа: Свой
Сообщений: 1 409
Регистрация: 22-05-07
Из: ExUSSR
Пользователь №: 27 881



Цитата(jcxz @ Jan 24 2018, 12:18) *
Любая из сторон TCP-сокета может передавать данные не дожидаясь подтверждений ранее переданного в пределах окна, которое было объявлено в последнем сообщении от 2-й стороны TCP-сокета.

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

А какой размер окна у стека модема на прием? Судя по отсутствию настроек и логики работы,
получается равным 1 байт. Сколько бы сервер ни прислал данных, модем обычно тут-же подтверждает.
Правильно?
Go to the top of the page
 
+Quote Post
jcxz
сообщение Jan 24 2018, 16:43
Сообщение #23


Гуру
******

Группа: Свой
Сообщений: 4 108
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713



Цитата(Alechek @ Jan 24 2018, 13:26) *
А причем тут TCP сокет?

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

Цитата(Baser @ Jan 24 2018, 15:52) *
Т.е. если это соединение Модем <-> Сервер, то размер для окна пакетов модема назначает сервер?

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

Цитата(Baser @ Jan 24 2018, 15:52) *
А какой размер окна у стека модема на прием? Судя по отсутствию настроек и логики работы,

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

Цитата(Baser @ Jan 24 2018, 15:52) *
Сколько бы сервер ни прислал данных, модем обычно тут-же подтверждает.

Нет, всё не так. TCP ack - это одно, а окно - другое. С ack-ом приходит новый размер окна. Пока он не пришёл - можно слать не более чем было указано в последнем ack-е.
Ack приходит всегда (если данные корректно приняты), но с задержкой. Приёмная сторона, приняв порцию данных, может её не сразу подтвердить, а через некоторое время. Это для сокращения пустого траффика.
Если же отправитель, будет отправлять данные малыми порциями и после каждой такой порции ждать ack (как делают многие криворукие программёры), то передача будет очень медленной.
Это всё описано в описании TCP-протокола.
Go to the top of the page
 
+Quote Post
Baser
сообщение Jan 24 2018, 22:57
Сообщение #24


Просто Che
*****

Группа: Свой
Сообщений: 1 409
Регистрация: 22-05-07
Из: ExUSSR
Пользователь №: 27 881



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

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

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

Цитата(CADiLO @ Jan 24 2018, 14:10) *
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.

Эдуард, не могли бы прояснить, не совсем понятно, как в этом режиме определить, что еще можно "пихать" модему данные на передачу.
Как можно узнать что заполнен приемный буфер и модем больше не может принимать данные?
Go to the top of the page
 
+Quote Post
Цырен.
сообщение Feb 1 2018, 09:28
Сообщение #25


Евгений
***

Группа: Участник
Сообщений: 339
Регистрация: 13-10-11
Пользователь №: 67 706



Цитата(Baser @ Jan 25 2018, 01:57) *
Как можно узнать что заполнен приемный буфер и модем больше не может принимать данные?


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


--------------------
Go to the top of the page
 
+Quote Post
wild.hamster
сообщение Feb 1 2018, 10:51
Сообщение #26





Группа: Участник
Сообщений: 12
Регистрация: 31-01-18
Пользователь №: 101 449



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

2 страниц V  < 1 2
Reply to this topicStart new topic
3 чел. читают эту тему (гостей: 3, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 21st February 2018 - 11:07
Рейтинг@Mail.ru


Страница сгенерированна за 0.01033 секунд с 7
ELECTRONIX ©2004-2016