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

Причем тут не получается? Элементарно бот находится за NAT к примеру, или ещё что. Туда куда домен нет смысла проводить или не нужно наоборот

С вебхуками ты открываешь соединение на получение и всё. Телега берёт на себя все расходы на доставку.

С вебхуками ты открываешь соединение на получение и всё. Телега берёт на себя все расходы на доставку.

и что в этом лучше или хуже?

С вебхуками ты открываешь соединение на получение и всё. Телега берёт на себя все расходы на доставку.

С вебхукахами ты ничего не открываешь, только получаешь пачку запросов

и что в этом лучше или хуже?

Очевидно лучше. Ты не обращаешься к серверу вообще.

Очевидно лучше. Ты не обращаешься к серверу вообще.

так а почему это лучше-то?

так а почему это лучше-то?

Тем что ты не спамишь запросами каждые Х секунд

ты открываешь целый ссл порт, к твоему сведению

Тем что ты не спамишь запросами каждые Х секунд

1 запрос один хук. За один Лонг пул можно вытащить пачку запросов

ты открываешь целый ссл порт, к твоему сведению

Да. И его можно ограничить на диапазон IP телеги. Я не вижу в этом проблемы

Тем что ты не спамишь запросами каждые Х секунд

а что экономится-то при

этом?

электроны в проводах?

1 запрос один хук. За один Лонг пул можно вытащить пачку запросов

А можно и не вытащить если их нет. В обеих случаях ты уже отправляешь запрос

И что?

Я отправляю запрос и жду получения

а что экономится-то при

Трафик? Пропускная способность?

Я отправляю запрос и жду получения

Отправляешь один запрос на установку вебхука и всё, ждёшь получения, да.

какой, блин, трафик на спящем 5,10,20.1000 секунд соединении, кроме возможно keep-alive?

С пулингом ты отправляешь запрос и надеешься что там что-то есть. Каждую итерацию.

Короче это пустой разговор

какой, блин, трафик на спящем 5,10,20.1000 секунд соединении, кроме возможно keep-alive?

Вот именно - почти никакого, если нет необходимости

С пулингом ты отправляешь запрос и надеешься что там что-то есть. Каждую итерацию.

не совсем так. Отправляется запрос, а на той стороне он "подвисает" до появления событий.

Короче это пустой разговор

Возможно.

Вот именно - почти никакого, если нет необходимости

тебе посчитать, сколько байт в день это занимает?

не совсем так. Отправляется запрос, а на той стороне он "подвисает" до появления событий.

Это не так.

Это не так.

это т ак.

ты просто, если точно не разбираешься, то послушай тех, кто понимает.

Спорить о том, что лучше, веб хуки или полинг, то же самое что спорить о том, что лучше, табуляция или пробелы

это т ак.

Возможно это так и выходит, но точно не во всех либах или языках.

Возможно это так и выходит, но точно не во всех либах или языках.

при чем здесь либы или языки?????

мы говорим про хттп запрос, или даже точнее про tcp соединение.

Ну, это первое что мне пришло на ум, что может "удерживать" запрос до получения чего-либо

Ну, это первое что мне пришло на ум, что может "удерживать" запрос до получения чего-либо

ну вот значит надо еще поизучать предмет

Т.е. каждый цикл - 1 запрос

я просто делал протоколы обмена с лонг-поллингом, и с клиентской стороны и с серверной.

Т.е. каждый цикл - 1 запрос

и что?

а если getUpdates() вернется с результатом только когда там что-то появится на другом конце?

и что?

Это должно быть довольно очевидно, что так делать не стоит, если есть возможность сделать проще.

Это должно быть довольно очевидно, что так делать не стоит, если есть возможность сделать проще.

где тут сложнее-то???

тивиальный ведь код!

тивиальный ведь код!

Я не про код, а про процесс получения обновлений

так он тоже тривиальный

почитай про tcp , про пакеты и про это все

а если getUpdates() вернется с результатом только когда там что-то появится на другом конце?

GetUpdates приходит сразу после запроса. Он может быть с обновлениями, а может и быть пустым, если обновлений нет

это short polling значит

а разговор про long

то есть, когда серверный конец задерживает результат то того момента, как там что-то появится значимое

так понятно?

время ожидания выставляется в несколько секунд просто для удобства

можно его в бесконечность поставить теоретически

то есть, когда серверный конец задерживает результат то того момента, как там что-то появится значимое

И от чего это зависит?

Я имею ввиду сам факт задержки запроса

зависит что именно?

Как ты можешь гарантировать чтобы сервер, который не под твоим контролем, подержал запрос до заполнения хоть чем-нибудь?

это не я гарантирую, а он :)

прикинь до чего техника дошла! %:)

это не я гарантирую, а он :)

А он и не гарантирует, в том-то и дело

Ты шлёшь обычный запрос на нужный адрес с нужными данными и получаешь ответ

Сразу, без задержек

Сразу, без задержек

нет.

Я имею ввиду без каких-то ручных задержек, а не задержек из-за нагрузки или других пробелм на сервере

я ставлю время ожидания и ничего мне не приходит, если событиц нет - соединение в это время висит.

Чувак, вот мне уже надоело с тобой спорить.

я ставлю время ожидания и ничего мне не приходит, если событиц нет - соединение в это время висит.

Т.е. тот самый параметр TimeOut, верно?

ERROR: S client not available

Ты бы послушал более опытных в разработке товарищей, и поучился бы.

Чувак, вот мне уже надоело с тобой спорить.

Окей, как скажешь. ¯\_(ツ)_/¯

long polling не телеграмом придуман, эта практика тыщщу лет уже применяется, когда данные надо слать с одной стороы, а соединение делать с противоположной.

серверная сторона тупо не шлет данные в tcp соединение, и все сидят и ждут

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

там есть некоторые сложности, но они совсем другого плана

На моем домашнем ноуте крутится домашний бот. там лонг полинг ждет по 5 минут. кто-то и по 10 ставил.

т.е 1 запрос в 5 минут.

например, если делать поллинг с бесконечным ожиданием, то может поекспайриться какая-нибудь таблица трансляции посередине на роутере

но там времена порядка десятков минут

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

чисто ленюсь :)

в теории лонгполлинг доставляет вам сообщения быстрее, чем вебхук

почему же?

так как в вебхуке сначала надо сделать ssl negotiation

а когда вы делаете запрос, то оно делается до того.

Но это чисто теория :) На практике не так :)

На пальцах если то примерно так -

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

отресолвила имя, сконнектилась с на его ип, потом начала проверять сертификаты, которые предъявил вебхучный сервер

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

Это так рабоает вебхук.

При поллинге, вся ссл байда выполняется сначала, потом мы коннектимся и засыпаем.

дожидаемся долгожданного события, и оно сразу летит к нам в виде хттп пейлоада.

Еще раз - на практике все это величины в пределах погрешности, и на них плевать.

По жесткому что-то виснет бот

@mpenzin правила чата не нарушайте

@mpenzin правила чата не нарушайте

ну то живая беседа была , в реальном времени :) А описание протокола разбито на смысловые секции

И тем не менее

Добрый день. Кто поможет сделать бота автопродаж?

Failed to get updates. Waiting: 1s { FetchError: request to https://api.telegram.org/botToken/getUpdates?offset=0&limit=100&timeout=30 failed, reason: connect ETIMEDOUT 149.154.167.197:443 at ClientRequest.<anonymous> (/root/m1000/node_modules/node-fetch/index.js:133:11) at emitOne (events.js:96:13) at ClientRequest.emit (events.js:191:7) at TLSSocket.socketErrorListener (_http_client.js:358:9) at emitOne (events.js:96:13) at TLSSocket.emit (events.js:191:7) at emitErrorNT (net.js:1283:8) at _combinedTickCallback (internal/process/next_tick.js:80:11) at process._tickCallback (internal/process/next_tick.js:104:9) name: 'FetchError', message: 'request to https://api.telegram.org/botToken/getUpdates?offset=0&limit= 100&timeout=30 failed, reason: connect ETIMEDOUT 149.154.167.197:443', type: 'system', errno: 'ETIMEDOUT', code: 'ETIMEDOUT' } Кто знает в чем трабла может быть ?