[CADiLO 8]

А чем плох сторонний ресурс? Всегда есть выбор, есть уровни доступа и так далее.

В 90% случаев работа с облаком это быстро, просто, удобно. 

Ну разве что у юзера ракетная телеметрия или уровень паранойи выше среднего.....

Тогда да - лучше помучиться чтобы с одним оператором - костыль номер два, а с другим костыль номер пять, а в соседнем ФО или стране вообще не работает.

 

[rudy_b 1]

Я правильно понял, вы намекаете на то, что в моих проблемах с UDP виноват оператор? А можно поподробнее, если несложно?

 

Решение через MQTT вероятно возможно, но как-то не очень хочется надеяться на чужого дядю, сегодня он есть, а завтра его нет.

 

1 hour ago, CADiLO said:

лучше помучиться чтобы с одним оператором - костыль номер два, а с другим костыль номер пять, а в соседнем ФО или стране вообще не работает.

Это меня тоже беспокоит и, думаю, универсального решения нет. GSM и сама по себе небольшой подарок, надежность ниже плинтуса.

[CADiLO 8]

Я намекаю на то? что нужно максимально дистанцироваться от проблем которые может создать оператор.

У него приоритет - интернет на гаджеты бытовых юзеров - а значит TCP/IP.

Ваши "железки" ему интересны только если вы готовы ему доплачивать за "белый" IP или пользоваться его облаком.

Поэтому будем хитрее хитрого - ему выгодно TCP? ОК. Мы уйдем в надстройку над ним но для своих целей. 

И пусть опсос думает что вы ютубите и стримите, а мы порешеаем свои проблемы.

 

Кстати вторая альтернатива - PUSH сообщения в телеграмме. Заменяет SMS аж бегом.

Реализация управления через их БОТ - только нужно вникнуть в АPI и все.

 

 

[rx3apf 0]

4 часа назад, CADiLO сказал:

В 90% случаев работа с облаком это быстро, просто, удобно. 

На счет просто - все равно не проще UDP на свой сервер ? "Быстро" - тоже сомневаюсь. Т.е., скажем, газосчетчику-то скинуть показания раз в сутки - без проблем. Но если данные поступают постоянно (трекер), или до клиента надо достучаться быстро - что-то я ОЧЕНЬ сомневаюсь в эффективности такого решения...

 

4 часа назад, CADiLO сказал:

Тогда да - лучше помучиться чтобы с одним оператором - костыль номер два, а с другим костыль номер пять, а в соседнем ФО или стране вообще не работает.

 

Если сегодня у оператора проблема с UDP, почему завтра не будет проблемы с TCP ? Может, лучше сразу такому оператору сделать ручкой ?

2 часа назад, rudy_b сказал:

Я правильно понял, вы намекаете на то, что в моих проблемах с UDP виноват оператор? 

Самое простое - ну возьмите карточку другого оператора ? Если ситуация останется прежней - оператор не виноват, придется внимательнее разбираться у себя. Проблема исчезнет - сделайте зарубку на память, чтобы по возможности избегать такого сомнительного сервиса. Мне еще помнится, что Мегафон еще и округляет трафик до неприличных цифр, а соединение до бесконечности держать не позволяет. Что уже минус для телеметрии.

 

[CADiLO 8]

>>>почему завтра не будет проблемы с TCP

 

Ответил выше - У него приоритет - интернет на гаджеты бытовых юзеров - а значит TCP/IP.

 

По поводу своего сервера - спорить не стану - задачи бывают разные и такое тоже востребовано.

Однако, не знаю как у вас, могу судить только по нашим юзерам - облака все популярнее.

На любой вкус и кошелек.

Для примера 

РФ - Яндекс и наверняка есть еще датацентры

У нас Киевский датацентр + операторские

Azure, Google, Xiaomi..... 

[rx3apf 0]

Кстати, совсем уж неприличный вопрос - а если к тому же серверу послать UDP-запрос, но не через мобильного оператора, а с "стационарного" (но не в локалке, а чтобы внешний ip был источником) - - работает ? А то ведь всякое бывает...

[CADiLO 8]

Если API облака позволяет, то будет работать.

Обычно в доках есть список того чем можно коннектиться.

Думаю что больше всего проблем именно у сотовой связи - NAT оператора штука непредсказуемая.

 

[rx3apf 0]

Не, это был вопрос к rudy_b - даже не меняя SIM, удостовериться со стороннего стационарного адреса, что логика сервера вообще работает правильно.

Изменено 11 марта, 2021 пользователем rx3apf

[CADiLO 8]

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

Извиняюсь, что принял вопрос к предыдущему обсуждению.

[rudy_b 1]

13 hours ago, rx3apf said:

Кстати, совсем уж неприличный вопрос - а если к тому же серверу послать UDP-запрос, но не через мобильного оператора, а с "стационарного" (но не в локалке, а чтобы внешний ip был источником) - - работает ? А то ведь всякое бывает...

Да, без проблем.

Но вот что меня смущает и заставляет думать, что я что-то не то делаю. Ведь запросы ping и NTP проходят нормально через соответствующие функции модема. А если посылаю их через UDP - не проходят (по крайней мере NTP). А ведь это тоже пакеты UDP.  Что-то тут не то, еще поиграюсь.

[rx3apf 0]

Ping ведь не UDP, а ICMP ? А вообще - сделайте, как я отлаживал - модем в прозрачный режим и к терминалке. Если есть "анизотропия" - меняем оператора, опять проверяем.

[rudy_b 1]

Это все равно UDP, просто в пакете ICMP строго определена структура данных.

[adnega 10]

11 минут назад, rudy_b сказал:

Это все равно UDP, просто в пакете ICMP строго определена структура данных.

UDP передается поверх IP, а ICMP это даже не IP.

ICMP это очень богатая сущность, а не только ping.

[rx3apf 0]

А там какого-то различия в заголовках нет (я не очень в теме, могу ошибаться) ? Если это вообще натуральный UDP, то тогда (тем более что срабатывает NTP), то тем более странно - все ж, похоже, косяк не у оператора. Методом исключения - оператор, модем (взять какой-нибудь SIM900, к примеру, или 800-й другой версии), сервер...

[rudy_b 1]

Не поленился и нарисовал свой сервер UDP. И вот что получилось.

Запускаю UDP на модеме, connect ->connect ok

Send ... ->send ok.

Мой сервер получает пакет, отвечает на него, но модем ответа не получает.

На все последующие send - модем нормально получает все ответы, вплоть до завершения сессии (disconnect, shut).

Т.е. пропадает только первый ответный пакет сервера после connect.

Пробовал поставить задержку ответа сервера на 10 сек - ровно то же самое.

При повторном запуске UDP - то же самое.

Чудеса... 

Зато стало понятно почему у меня NTP через UDP не работал, я не делал повторных попыток получить время, точнее делал, но каждый раз перезапускал сессию UDP. А надо было сделать несколько попыток в одной сессии.