А можно поподробнее? у меня у заказчиков "в Москве с айфонов при использовании мобильного интернета" сервис не открывается, при этом замена любого компонента по отдельности (другой город РФ, с андроида, через wifi) проблему решает. Сам я не в Москве, проверить многие догадки самостоятельно не могу.
Сначала корейская война заморозилась же, которая прям активная была, причем почти сразу... А карибский кризис еще почти через 10 лет и связан с другими обстоятельствами.
Нет, не у вас, а на сервере, через который вы раздеградируете ютуб входящий и исходящий трафик симметричен и +- равен, и на этот сервер не надо даже заходить и не надо никаких открытых портов, ничего, чтобы это увидеть.
на каждый из этих 2 квн-серверов будет на одного 100% исходящий трафик
Нет, там будет симметричный трафик, просто на одном будет входящий от вас к серверу и равный исходящий от сервера в пункт назначения, а на втором - входящий от пункта назначения и равный ему исходящий до вас.
У файлообменника как правило исходящий трафик будет больше входящего, ибо скорее всего файл скачивают больше одного раза, да и в любом случае закачка и скачивание происходят в разное время. У ВПНа, если там больше ничего нет - чаще всего "в квант времени" исходящий и входящий трафик будет +- совпадать. После определения этого (отсеяв бОльшую часть легитимного) этим сервером уже можно заняться плотнее, анализировать адреса, протоколы и прочее.
Когда такой быстрый анализ все начнут массво обходить - будет что-то другое уже, но сейчас это работает.
Заодно, раз уж читал подряд, наткнулся на старую жалобу про телефон — ещё в самом первом отзыве писали, что пальцем не всегда попадаешь по кнопкам управления, а san4ez_gig прямо предлагал сделать их покрупнее. Увеличил кнопки и зазоры между ними — раньше на короткой альбомной ориентации интерфейс просто вылезал за экран. Надеюсь, теперь не будет больше проблем на мобильной версии.
Может проще добавить для мобильных устройств управление поворотом устройства свайпами?
Кажется, вероятность стать winner с каждой следующей итерацией приведенного алгоритма падает, в то время как вероятность остатка от деления всегда одинакова.
Просто приложенный алгоритм как-то не очень равновероятен. ИМХО, сложить все дескрипторы в память вряд ли займет ощутимое количество памяти, даже относительно размера самой картинки, под которую память аллоцируют после этого.
И то, что EDT прослойка не то, чтобы ненужная, но с гиганстким оверхедом, из-за чего время "изменил код-проверил" вырастает кратно для небольших изменений.
Вообще имхо jwt нужны только для микросервисной архитектуры чтобы передать информацию типа user_id с подтверждением валидности между теми самыми сервисами. Для обычных приложения вида "фронтэнд + бэкэнд" это избыточно. В некоторых моих проектах клиент вообще не знает своего id (или производных типа profile_id) (он на него вообще не передается ни в каком виде) и все нормально. Естественно, в таких проектах нет p2p взаимодействий, это b2c штуки.
Так он и сейчас не запрещает. Там нужно, чтобы копия была локализована (и сохранена в пакете яровой).
А можно поподробнее? у меня у заказчиков "в Москве с айфонов при использовании мобильного интернета" сервис не открывается, при этом замена любого компонента по отдельности (другой город РФ, с андроида, через wifi) проблему решает. Сам я не в Москве, проверить многие догадки самостоятельно не могу.
На сервисе и так TLS 1.2 включен, 1.3 выключен.
А откуда аплинк на спутники пришел? Была ли передача спутник-спутник?
Сначала корейская война заморозилась же, которая прям активная была, причем почти сразу... А карибский кризис еще почти через 10 лет и связан с другими обстоятельствами.
Нет, не у вас, а на сервере, через который вы раздеградируете ютуб входящий и исходящий трафик симметричен и +- равен, и на этот сервер не надо даже заходить и не надо никаких открытых портов, ничего, чтобы это увидеть.
Нет, там будет симметричный трафик, просто на одном будет входящий от вас к серверу и равный исходящий от сервера в пункт назначения, а на втором - входящий от пункта назначения и равный ему исходящий до вас.
В вашей схеме все равно на каждом из узлов трафик все равно будет симметричный. Но я уже написал - пока и так работает.
У файлообменника как правило исходящий трафик будет больше входящего, ибо скорее всего файл скачивают больше одного раза, да и в любом случае закачка и скачивание происходят в разное время. У ВПНа, если там больше ничего нет - чаще всего "в квант времени" исходящий и входящий трафик будет +- совпадать. После определения этого (отсеяв бОльшую часть легитимного) этим сервером уже можно заняться плотнее, анализировать адреса, протоколы и прочее.
Когда такой быстрый анализ все начнут массво обходить - будет что-то другое уже, но сейчас это работает.
Можно просто сравнить объем входящего и исходящего трафика.
Я думал, тут прям совсем очевидно
Ну вот, судя по новостям, через пару дней после этой статьи пошла волна банов: https://t.me/sysodmins/29870
Скрытый текст
Пришлите фотографию вашей банковской карты с двух сторон, чтобы проверить, есть ли она в базе данных мошенников.
Какой ужас.
Может проще добавить для мобильных устройств управление
поворотом устройствасвайпами?Спасибо за пояснение. Что-то я затупил.
Кажется, вероятность стать winner с каждой следующей итерацией приведенного алгоритма падает, в то время как вероятность остатка от деления всегда одинакова.
Просто приложенный алгоритм как-то не очень равновероятен. ИМХО, сложить все дескрипторы в память вряд ли займет ощутимое количество памяти, даже относительно размера самой картинки, под которую память аллоцируют после этого.
А просто равновероятный getTickCount() % variansCount слишком сложно?
И то, что EDT прослойка не то, чтобы ненужная, но с гиганстким оверхедом, из-за чего время "изменил код-проверил" вырастает кратно для небольших изменений.
Еще и дополнительные баги привносящая.
Вообще имхо jwt нужны только для микросервисной архитектуры чтобы передать информацию типа user_id с подтверждением валидности между теми самыми сервисами. Для обычных приложения вида "фронтэнд + бэкэнд" это избыточно. В некоторых моих проектах клиент вообще не знает своего id (или производных типа profile_id) (он на него вообще не передается ни в каком виде) и все нормально. Естественно, в таких проектах нет p2p взаимодействий, это b2c штуки.