pfg21, аналогичная беда была в некоторых сетевушках и помогало в винде включить Wake-On-Lan в свойствах драйвера, чтобы сетевушка не гасилась при завершении винды...
ToS это скорее подсказка промежуточным узлам, никаких чудес она не создаёт, ну и скорее всего большиство маршрутизаторов его проигнорируют. Но поставить можно, никто ж не запрещает.
Чтобы управлять трафиком, следует смотреть в сторону traffic control и скорее всгео выделить DC-клиент в отдельную cgroup. Там нужно будет выкурить документации, начиная с lartc.org.
Про винду не знаю, в Linux есть ionice, которым можно понизить для конкретного процесса приоритет ввода-вывода. Может, в винде у системы тоже есть какие-то подобные механизмы?
RimMirK, чепуха, в реальности по скорости никакого "напрямую" не будет. Придётся выкачать весь файл и загрузить в Телеграм, потом только отправить сообщение, в котором передать file_id. Этот file_id в любом случае надо прикопать, чтобы не скачивать одни и те же видео несколько раз.
А ещё возникнет проблема с тем, что видео сейчас чаще всего нарезаны в фрагменты, и для получения нормального видеофайла на них надо применить фильтр aac_adtstoasc. Сделать это можно только полным выкачиванием файла. Увы, но нет.
И это ещё не обсуждается вопрос надёжности (обрывов связи итд) и тем более скорости. Например, популярный кодик лимитирует скорость скачивания в зависимости от битрейта (на величину примерно 2x битрейт, то есть смотреть на скорости x2 можно, а качать быстрее нельзя). А ведь это крупнейший и и наиболее очевидный источник пиратского видео. Юзер запросит фильм а ему "ждите ещё 4 часа своей очереди и 2 часа на скачивание самого видео" :)
Короче, затея с самого начала дохлая. Это нужно вложить кучу сил, времени и ресурсов, причём ещё и постоянно поддерживать всё это на плаву, отслеживать живость загруженных в Telegram файлов, корректировать парсеры источников итд итп...
Надёжнее тырить контент у других "кинотеатров" (ловить у них парсером file_id загруженных фильмов, собирать в свою базу, чтобы отправлять от своего имени). Тоже не суперзатея, но более реалистично в режиме "не качая".
Ну в целом я бы посоветовал найти другую идею для своего личного вау-проекта...
Vladislav, flash call невыгоден операторам (невзятый звонок бесплатен) и они с этим борются. Поэтому работает это не очень надёжно и может регулярно отваливаться.
СМС для A2P стоят очень дорого, да. Раньше операторы оправдывались борьбой со спамом (и это даже правда, потому что высокие цены на деле сильно уменьшили объёмы спама в СМС), но уже давно превратилось в кормушку операторов - они частично компенсируют недополученную прибыль от абонентов, состригая её с бизнесов. Можно сделать дешевле только за большие объёмы и шаблонирование трафика, но сайту с какой-нить жалкой тыщей СМС в месяц это не светит.
Обычная практика - это, например, регистрация через соцсети. Фактически проблема регистрации перекладывается на соцсеть. Не супернадёжно, зато бесплатно.
EgorKhabarov, надо посмотреть в первую очередь в описание родного API, ведь именно по нему работают официальные клиентские приложения. Не исключено, что telethon просто ещё не знает про новые фичи. Или, как вариант, они слишком в неочевидном месте находятся, и их нужно как-то откопать.
EgorKhabarov, нет, он не получает эту информацию через Bot API, поскольку - повторюсь - в Bot API эта информация не предоставляется. У этого бота есть вторая интеграция с Telegram на базе MTProto, которая это и делает.
Руслан Федосеев, да, я когда начинал писать комментарий, хотел про него упомянуть но потом забыл. В каком-то смысле jabber пример даже лучше, потому что в отличие от AD это не один-единственный софт от одного производителя, а реальный базар многообразного софта, в котором, тем не менее, SRV реализуется практически всегда.
mayton2019, в реальном мире SRV мало кто поддерживает, потому что нельзя угадать, подумали ли об этом авторы конечного софта. Например, далеко не каждая почтовая программа догадывается, что бывает запись _imap._.tcp у домена. И ладно если это что-то для автонастройки, как в приведённом примере, а если бы это было что-то, что без SRV-записи не работало бы?
Исключения, конечно, есть. Например, jabber-клиенты и jabber-серверы неплохо поддерживают SRV, потому что там указывается адрес сервера куда посылать сообщения на домен - нечто подобное MX для почты. Клиент или сервер, не поддерживающий SRV-записей, в мире jabber был бы не очень интересен, так как сервер jabber может находиться не на том же физическом сервере, куда указывает основная A или CNAME запись домена.
А netflix, конечно же, не заинтересован публиковать в SRV-ззписях свою внутреннюю кухню.
ld6666666666666, можно счётчик хранить в самом скрипте, в базе итд, ну а если это телеграм-бот есть довольно эффектное решение - брать update_id запроса или message_id сообщения и выводить "Да" если он делится на 9. Правда, в этом случае ротация будет общая на всех пользователей. Плюс возможны спецэффекты, если будут прилетать события и сообщения других типов. Если надо каждому пользователю свой счётчик то это не поможет.
