Нет ли где внятного описания чего означают каждый из вариантов возвращаемый по запросу
AT+CIPSTATUS

В частности сильно интересует что означает статус
STATE: TCP CONNECTING

ЗЫ. Модем Sim900

Диаграмму состояний (граф переходов) встречал в AN_SIM900_TCPIP_Application_Note
Но собственно описания там нет, по паре слов на каждое состояние, которые и так вытекают из его названия.

Вообще, большая часть стандартов GSM написана так, что чаще всего описывают только форму команды.
Смысл же или для чего это вообще нужно, описывается крайне редко
Типа: спец и так знает, а посторонним нефиг и лезть...

Ту диаграмму я видел и даже надеялся что она полная. Вот только кольцо которое там "слегка" не так работает как в реальности. К примеру переходит из STATE: TCP CLOSED в STATE: TCP CONNECTING минуя половину графа.

скорее не минуя, а очень быстро перебирая...
есть аналогичный озвученному Baser'ом для 900й серии, документ для 800й серии, напишите мне - пришлю (wirelessДОГmt-system.ru).

На сайте "Гаммы" (microchip.ua) этот документ (v1.01) лежит открыто, но там по графу состояний нет отличий от документа на SIM900.
Там только все облагородили и добавили главу "Two GPRS Context". Больше разницы не заметил.

По графу состояний для того, что-бы попасть из TCP CLOSED в TCP CONNECTING необходимо пройти всю цепочку начиная как минимум с IP INITIAL и как минимум в четырех точках для дальнейшего движения по графу ожидать моих данных или команд(AT+SIPSHUT, AT+CSTT, AT+CIICR, AT+CIFSR), но такого нет. Вот и хотелось-бы узнать более полный граф - т.е. куда и какими командами между состояниями можно попасть помимо того, что указано в SIM900_TCPIP_Application_Note. Потому как метод научного втыка конечно рулит, но хотелось-бы представлять и что создатели имели ввиду...

ЗЫ. Я так понимаю по 800-ке ситуация примерно аналогична...

установление TCP-соединения.

Первая половина графа относится к "bearer"-соединению с провайдером, в результате которого последний выделяет IP сим-карты.
Вторая половина графа - TCP-соединения в обычном сетевом смысле.
Поэтому для переоткрытия ТCP - соединения, процедуры относящиеся к "bearer", которым соответствует добрая половина графа в начале, необязательны.

Давно хотел узнать что это за bearer такой и почему есть два типа соединений - с bearer (HTTP) и без (TCP).

"bearer-соединение" - это Ваше соединение с провайдером. Все остальное - как HTTP так и ТСР - это соединение провайдера от Вашего лица с конечным адресом.

Для лучшего понимания бытовая аналогия: есть домашний роутер подключенный проводами к провайдеру, который раздает WiFi на все планшеты и ноутбуки в квартире. В этом случае роутер выполняет роль провайдера, а 5-метровый WiFi - "bearer"-соединение.

PS: я не специалист и если мое понимание ошибочно, надеюсь знатоки поправят.

Так а почему для HTTP надо "bearer-соединение", а для TCP надо "PDP-context".

Во-первых, понятия HTTP и TCP не являются достоянием мобильной связи, это общая теория сетей с их уровнями.
Во-вторых, HTTP и TCP не подлежат такому сравнению, потому что прикладной HTTP на транспортном уровне является TCP.
Поэтому, для HTTP, так как это TCP, также нужно "bearer-соединение".

В терминах "PDP-context" это выглядит так: при запросе клиента, как на стороне модема, так и на стороне провайдера
создаются структуры данных, называемые "PDP-context", в которые заносится информация о идентификации клиента и приобретенных
клиентом в пакете услуг благах: белый или динамический адрес, уровень качества предоставляемого сервиса и прочее.
Вот такое взаимное выделение этого контекста можете считать установившемся "bearer-соединением".

А далее - стандартная матрешка: PDP внутри содержат TCP, которые в свою очередь содержат HTTP.

Повторяюсь, для работы с HTTP нужно "bearer-соединение", для работы с TCP "bearer" не нужно, а только PDP-context. Почему так по разному? Ведь на транспортном уровне там все равно TCP в обоих случаях.

Весь вопрос как раз в том почему для TCP не нужно "bearer-соединение".

Потому что в той документации инструментария, которую Вы используете слишком вольно пользуются терминологией.
Контекст - это всего лишь запись в базе данных на "APN-сервере" провайдера, что обладатель конткретной симки купил
услугу GPRS определенного тарифа и что на его счету что-то еще есть.
Это необходимое условие, но недостаточное: для TCP, как и для всего прочего по GPRS, нужна "активация PDP-контекста", что на сленге именуется "bearer-соединением".

Из-за путаницы в терминологии получается приблизительно как "нужен hard disc, а не винчестер".

Так ведь и команды подъема соединения совершенно разные, для FTP/HTTP - AT+SAPBR, для TCP - AT+CSTT, AT+CIICR. Это что, внутри SIM800C одно и то же? Или внутри совершенно разный код для одного и того же? Или для FTP/HTTP код студетны делали с нуля не знаю о готовой реализации для TCP?

Команды разные, в силу того, что в случае для FTP/HTTP вы сообщаете о намерении использовать соответствующий протокол прикладной протокол - SIM800C в этом случае все равно выполняет вначале действия аналогичные для TCP-команд.
Грубо говоря, если Вы вручную реализуете ftp- или http- сервисы посредством команд для TCP, то это и будет тем, что делают
команды для для FTP/HTTP.

Это скорее HTTPINIT.



Не похоже что одно и то же. Если там внтури это одно и то же по сути, то не понимаю почему при варианте реализации HTTP через TCP от SIM800C запрос выполняется почти в два раза быстрее чем при использовании HTTP от SIM800C.

HTTP:

Около 2-х сек.

TCP:

Около 1-й сек.

Чисто теоретически вариант реализации через TCP будет быстрее варианта HTTP, потому что TCP - это "stream"-сокет, который ретранслирует данные между Вами и конечным адресатом, а HTTP - это такой же "stream"-сокет, возле которого в качестве цензора сидит встроенный HTML-сервис SIM800C. Который забирает на свою работу часть времени и которую Вы в случае реализации через TCP должны выполнять самостоятельно, но уже после остановки секундомера.
А в приведенном Вами коде я не увидел, что запросы идентичны: в случае HTML запись GET с последующим чтением результата, а в случае TCP - только запись.