С сервером соединяется по http. Типа web страницы открывает. А на самом деле шлёт данные
Так вот у всех клиентов работает отлично
Но у двоих работает какое-то время, потом перестаёт
У одного 10 мин работает, потом 30 мин не работает
У второго 1 час работает, потом 1 день не работает
Я думаю их интернет провайдер считает, что это спам, слишком много http запросов на один адрес
Какой-то счётчик переполняется и лочит на заданное время
Здравствуйте, TailWind, Вы писали:
TW>Написал я прогу — Remote Desctop TW>15 раз в секунду она шлёт снимки экрана на сервер
Курить Transfer-Encoding: Chunked и не морочить людям мозг.
Здравствуйте, TailWind, Вы писали:
TW>Написал я прогу — Remote Desctop
TW>15 раз в секунду она шлёт снимки экрана на сервер
TW>С сервером соединяется по http. Типа web страницы открывает. А на самом деле шлёт данные
А если типа как один большой файл загружать по http? А вообще наверно лучше websocket или вообще бинарный протокол.
Здравствуйте, TailWind, Вы писали:
TW>Но у двоих работает какое-то время, потом перестаёт TW>У одного 10 мин работает, потом 30 мин не работает TW>У второго 1 час работает, потом 1 день не работает
Любое "не работает" должно быть представлено в виде конкретного описания ситуации. Например, может быть один из вариантов: не резолвится доменное имя; коннект не проходит с таймаутом; коннект получает немедленный отказ; коннект проходит, но на запрос нет ответа; другое.
Пишите лог и просите юзера перекинуть его, или пусть программа сама присылает лог.
TW>Я думаю их интернет провайдер считает, что это спам, слишком много http запросов на один адрес TW>Какой-то счётчик переполняется и лочит на заданное время
Вероятность есть, но невысокая.
TW>Есть какие-то идеи, как с этим бороться?
Не запускать каждый раз новое соединение. Открыть один websocket и держать открытым.
Вместо полного снимка передавать дифф от предыдущего (может, 2-3 предыдущих, если меняются несколько типовых), плюс небольшой квадратик полностью (для очистки от проблем кривой передачи или кривого вычисления диффа).
N>Любое "не работает" должно быть представлено в виде конкретного описания ситуации.
Прошу прощения. Не подумал
У этого клиента: Connection timeout и 10060 (тоже timeout) начинает валить
При этом TeamViewer тоже начинает тормозить
Так что может быть и не моя проблема
Timeout у меня 3 секунды
У второго клиента другой был код. Но сейчас уже не вспомню какой
N>Пишите лог и просите юзера перекинуть его, или пусть программа сама присылает лог.
Да, я могу смотреть лог через TW
TW>>Есть какие-то идеи, как с этим бороться? N>Не запускать каждый раз новое соединение.
Так я сокет и не закрываю
Если это важно, их 5 штук в разных потоках
N>Открыть один websocket и держать открытым.
Я не понимаю как работает websocket
Как это обрабатывть на стороне сервера (php)?
N>Вместо полного снимка передавать дифф от предыдущего (может, 2-3 предыдущих, если меняются несколько типовых), плюс небольшой квадратик полностью (для очистки от проблем кривой передачи или кривого вычисления диффа).
Так и делаю
У 99% клиентов работает отлично
Q>А если типа как один большой файл загружать по http?
Так большой файл так и загружают
Делят на пакеты
И каждый пакет отдельным http запросом отправляют
С такой загрузкой проблем не возникает
Так как пакеты большие и идут редко
А тут у меня мелкие пакеты с 15 FPS
Q>А вообще наверно лучше websocket или вообще бинарный протокол.
Не понимаю как с этим работать на стороне сервера (php)
Здравствуйте, TailWind, Вы писали:
Q>>А если типа как один большой файл загружать по http? TW>Так большой файл так и загружают TW>Делят на пакеты TW>И каждый пакет отдельным http запросом отправляют
Имелось ввиду один запрос — один файл без конца, а кадры уже внутри бинарного потока. Ну естественно сервер должен уметь с этим работать.
Нет всё таки моя
Это случается регулярно
Я думаю провайдер интернета у клиента ограничивает ему временно пропускную способность или типа того
Чтобы не спамил
Здравствуйте, TailWind, Вы писали:
TW>У этого клиента: Connection timeout и 10060 (тоже timeout) начинает валить TW>Так я сокет и не закрываю
Вот отсюда можно начинать копать. Как вы получаете "таймаут соединения", если не открываете новых сокетов? Или наоборот, сокеты открываете и не закрываете?
Чтобы лучше представлять проблему, несколько вопросов. Какая версия HTTP используется? Какие заголовки отдает сервер (в особенности — Connection)? Http или https? Какой http-клиент в приложении и как настроен? (всякие max connection per host, etc...). Таймаут в 3 секунды — это какой именно: на соединение, на чтение или оба?
В рамках connection timeout еще интересно увидеть самую первую ошибку при работе с сервером. Т.е. у вас всегда connection timeout или все начинается с read timeout и потом уже валятся connection?
И более глобальный вопрос. Как вообще реагирует приложение на медленную сеть? Ограничивает ли максимальное число соединений, которые пытается установить? Вот у вас таймаут в 3 секунды. Будет приложение пытаться открыть 3*15=45 соединений одновременно (каждое из которых отвалится по таймауту) или будет пытаться открыть всего 5 (по числу потоков)? Провайдер вполне может ограничивать общую пропускную способность. Называется это fair use. Т.е. "у нас гигабит, но если вы его будете использовать больше часа, мы вам ограничим скорость до 64kbit/sec". Это влияет на все пакеты. И в зависимости от вашей стратегии управления соединениями, вы можете либо стабильно получать таймаут, либо некоторые соединения иногда все же будут проходить.
P.S. DDOS — distributed denial of service. Т.е. распределенная. Вряд ли у клиента провайдер считает это именно распределенной атакой.
Здравствуйте, TailWind, Вы писали:
TW>У этого клиента: Connection timeout и 10060 (тоже timeout) начинает валить TW>При этом TeamViewer тоже начинает тормозить TW>Так что может быть и не моя проблема
Тормозящие сетевые приложения — хороший намёк что связь в целом начинает страдать.
Если дешёвый маршрутизатор дома, то узким местом становится именно он, и не важно что за бренд — DLink, TP-Link, младший Cisco (потому что кроме шильдика его со старшими братьями ничего не объединяет). Помнится, я как-то IP TV так пробовал на своём первом DLink: сначала идёт несколько секунд, затем кадры на экране теряются, затем маршрутизатор уходит в ребут, далее по кругу. Или например можно было машину со скайпом заблочить правилом на маршрутизаторе от интернета, и запретить скайпу в настройках UPnP. Тогда этот хитрец начинал по циклу перебирать все порты в процессе коннекта (видно в логах маршрутизатора) и в какой-то момент эти попытки тоже сваливают маршрутизатор в ребут (но там долго, минут 15-20 надо ддосить).
M>Вот отсюда можно начинать копать. Как вы получаете "таймаут соединения", если не открываете новых сокетов? Или наоборот, сокеты открываете и не закрываете?
Он после ошибки закрывается. И открывается заново
M>Чтобы лучше представлять проблему, несколько вопросов. Какая версия HTTP используется? Какие заголовки отдает сервер (в особенности — Connection)? Http или https? Какой http-клиент в приложении и как настроен? (всякие max connection per host, etc...). Таймаут в 3 секунды — это какой именно: на соединение, на чтение или оба?
HTTP/1.1
Http, не https
//Какие заголовки отдает сервер (в особенности — Connection)?
Это мне сложно сейчас достать
//Какой http-клиент в приложении и как настроен?
win32 сокеты обычные
//Таймаут в 3 секунды — это какой именно: на соединение, на чтение или оба?
Оба одинаково 3 секунды
M>В рамках connection timeout еще интересно увидеть самую первую ошибку при работе с сервером. Т.е. у вас всегда connection timeout или все начинается с read timeout и потом уже валятся connection?
Сложно это. Там же 5 потоков
Я с трудом структуру программы в голове держу
В лог сыпятся и connection и read timeout'ы
M>И более глобальный вопрос. Как вообще реагирует приложение на медленную сеть?
Уменьшает FPS
Но потоков (открытых сокетов) всегда ровно 5
M>Провайдер вполне может ограничивать общую пропускную способность. Называется это fair use. Т.е. "у нас гигабит, но если вы его будете использовать больше часа, мы вам ограничим скорость до 64kbit/sec". Это влияет на все пакеты. И в зависимости от вашей стратегии управления соединениями, вы можете либо стабильно получать таймаут, либо некоторые соединения иногда все же будут проходить.
Там когда на экране ничего не происходит. Он почти пустые пакеты шлёт.
Хотя 64k в секунду это мало..
M>P.S. DDOS — distributed denial of service. Т.е. распределенная. Вряд ли у клиента провайдер считает это именно распределенной атакой.
Сори. Не спец в сетях )
M>Провайдер вполне может ограничивать общую пропускную способность. Называется это fair use. Т.е. "у нас гигабит, но если вы его будете использовать больше часа, мы вам ограничим скорость до 64kbit/sec". Это влияет на все пакеты. И в зависимости от вашей стратегии управления соединениями, вы можете либо стабильно получать таймаут, либо некоторые соединения иногда все же будут проходить.
Здравствуйте, TailWind, Вы писали:
TW>HTTP/1.1 TW>Http, не https
Ок. В теории, провайдер может пытаться проксировать соединения. Маловерятно (большинство соединений в интернете сейчас https), но все же. Зато меньше накладных расходов на установление соединения. И минус потенциальные проблемы с сертификатами (OSCP).
TW>win32 сокеты обычные
Вопрос про заголовки снимается . Значит вы хорошо представляете жизненный цикл сокета.
TW>Я с трудом структуру программы в голове держу
Это этап, где может быть выгодно начать рисовать диаграмы, чтобы не хранить все в голове. Просто неформальная структура программы на листочке может быть очень полезна. Часто разработчики забывают про такую возможность.
TW>В лог сыпятся и connection и read timeout'ы TW>Уменьшает FPS Но потоков (открытых сокетов) всегда ровно 5
Согласуется с тем, что снизилась скорость сети. В зависимости от везения, теряются как пакеты с данными, так и пакеты на установку соединения. Хорошо, что приложение может уменьшать FPS. Может, в порядке эксперимента повысить таймауты для данных клиентов и посмотреть, будет ли стабильность лучше?
TW>Хотя 64k в секунду это мало..
Я здесь немного преувеличиваю. С другой стороны, это может быть вполне реальное ограничение на асимметричных сетях (ADSL и подобные). Там даже изначально upload раз в 10 меньше download. И провайдеры могут дополнительно резать скорость загрузки. Некоторые это делают для борьбы с торрентами. Т.е. "загрузить котиков в e-mail" скорости хватает, а для постоянной раздачи — нет.
Есть возможность попросить клиентов погонять что-нибудь вроде speedtest.net до начала использования приложения и после появления проблем? Может быть, это покажет проблему. А может — нет. Зависит от того, режет ли провайдер скорость к определенным адресам или глобально. А еще некоторые провайдеры специально не ограничивают трафик к таким сервисам проверки скорости, так что имеет смысл посмотреть еще и на несколько возможных альтернатив для замера пропускной способности.
Но у двоих работает какое-то время, потом перестаёт
У одного 10 мин работает, потом 30 мин не работает
У второго 1 час работает, потом 1 день не работает
а вы точно какое то отношение к ИТ имеете ?
потому что после таких выводов можно решить что вы ИТ мимикрокодил
M>Есть возможность попросить клиентов погонять что-нибудь вроде speedtest.net до начала использования приложения и после появления проблем?
Блин
Не могу повторить проблему
1. Установить на ваш сервер iperf3. Найти несколько публичных серверов в разных странах и на разных континентах с доступным iperf3, заранее проверить, что они выдают нормальную скорость.
2. Когда у человека начнёт тормозить ваша программа, в этот момент нужно ему установить iperf3 и проверить проходимость пакетов во-первых до вашего сервера с вашей программой, во-вторых до других серверов.
Если iperf3 не покажет проседания скорости до вашего сервера, вероятно проблема в вашей программе.
Если iperf3 покажет проседание скорости до вашего сервера, но не до других серверов, вероятно провайдер зарезал скорость конкретно до вашего сервера. Тогда вам поможет переработка архитектуры вашего решения, чтобы при медленной скорости программа переключалась на другой сервер.
Если iperf3 покажет проседание скорости до всех серверов, то либо провайдер тупо режет скорость из-за превышения каких-то лимитов, либо у человека роутер не очень работоспособный и, например, перегревается. Тут вы уже ничего не сможете сделать.
