Нет никакой трубы STUN/TURN. STUN (Session Traversal Utilities for NAT) это сервер, который позволяет проковырять дырку в NAT и одновременно узнать свой внешний айпишник. Через него трафик не идет. Используется только для установления соединения. Знать свой айпишник для работы с ним не надо.
TRUN (Traversal Using Relays around NAT) - это сервер для relay трафика. Вот тут уже труба. Но тут опять же никаких своих внешних айпишников знать не надо, вы подключаетесь к серверу и он вам отвечает трафиком, предназначенным для вас.
Вот как это работает в webrtc: Клиент1 и клиент2 за NATами. Клиент1 посылает STUN серверу запрос, получает ответ со своим внешним айпишником и портом. Их сервер видит в адресе отравителя во входящих пакетах. Роутер Клиента1 видит UDP трафик туда-сюда и держит порт открытм. Клиент2 получает эти данные в RemoteOffer, который приложение webrtc должно как-то через свой сервер передать. Клиент2 отправляет данные на этот известный айпишник и порт, NAT пересылает их Клиенту1. Это не работает для NATов, которые назначают порт отдельно для каждого адреса отправителя. Они не сопоставят трафик от клиента2 с трафиком от STUN сервера. Это частая штука на самом деле. В этом случае подключение должно идти через TURN relay.
Можно обойтись без STUN/TURN серверов, если у клиента1 белый айпишник, или администратор сети настроил DMZ, и можно настроить конкретный порт для подключений, что фактически тождественно белому айпишнику. Тогда клиент2 посылает данные на известный белый айпишник и так устанавливается соединение через все NATы перед клиентом2.
Это ваш случай и он частный. Тут нет STUN/TURN вообще, но это возможно только в сети, которую вы контролируете.
Опять же, тут приложению не надо как-то отдельно узнавать свой внешний айпишник во время работы. Или оно его уже должно знать в конфиге вместе с DMZ портом (который вы никаким сервисом в интернете не определите), или это все произойдет автоматически внутри STUN, или оно его видит на сетевом инетрфейсе, если айпишник белый.
Эта история совсем про другое. Вы тут у себя в сети настраиваете свой сервер. Это все не применимо к случаю клиентского приложения, запущенного у клиента в неконтролируемых вами условиях. Как вы вообще будете настраивать DMZ в сети провайдера, за которым сидит клиент?
Возможно, реализация именно от Microsoft такая (STUN/TURN должны быть RFC).
Нет, это потому что тут разговор про СЕРВЕР STUN, который сам должен быть доступен к подключениям из интернета. А не про клиент, который к серверу подключается из-за NATa.
Это еще что! Закладка может быть в компиляторе. При чем такая, что она в программы бекдор вставляет, и в исполняемый файл компилятора вставляет сама себя, хоть ее в исходниках и нету. А в дизассемблеры вставляет код, скрывающий себя. В итоге ее нигде не видно если вы только машинный код не читаете, даже если самостоятельно все из выученных наизусть исходников собирать.
Во-первых, DirectX это не только про 3d графику или игры, как вы, наверное, думаете. Там очень много всего буквально для рендеринга текста и картинок.
Во-вторых, зачем именно DirecX а не другое единственное виндовое апи для "рендеринга картинок и текста" GDI вы поймете, когда отключите аппаратное ускорение в настройках хрома. Потому что GDI не аппаратно ускорено.
В-третьих, кроме рендеринга картинок и текста, еще надо декодировать и рендерить видео. Очень много видео. Это тоже DirectX.
В-четвертых, по этим же самым причинам directx использует, например, и Firefox.
Для установки P2P-соединения (звонков) технология WebRTC требует внешний IP, чтобы построить прямой маршрут «телефон-телефон». Это стандарт для всех сервисов, которые осуществляют звонки при помощи данной технологии;
Как один из разработчиков WebRTC утверждаю, что - нет, не требует. Оно само определяет внешний IP, для этого надо указать хотя бы один STUN сервер, который и внешний IP определит и дырку в NATе проковырает, если сможет. А если не сможет, то можно WebRTC еще указать TURN сервер для туннелирования трафика. MAX же обращается не к STUN серверам. Во-первых, у них адреса другие, во вторых STUN протокол видно в дампе трафика.
Руками собирать внешний IP адрес никакого смысла нет. Это совершенно кривое использование WebRTC. Там надо будет еще поизвращаться, чтобы этот внешний IP в него засунуть.
Тут можно было бы еще предположить, что у разработчиков лапки и они не умеют использовать WebRTC. Но это опровергается списком посещяемых адресов. Зачем их столько? Зачем обращаться к заблокированным в россии серверам?
Теория о том, что макс используется как бекдор для роскомпозора для проверки блокировок и детектирования способов их обхода - гораздо более правдива.
Там не сильно много транзисторов надо для неурезанного. Через ИЛИНЕ объединяем все лишние биты, а потом это через И со всеми битами вывода. Когда-то это сделали для экономии, да. Но с тех пор пол века прошло, наверное и можно было бы и сделать по нормальному, но обратная совместимость ломается.
Видимо, изначально дизайнеры x86 не думали, что кому-то может понадобиться сдвигать надеясь, что переполнение все занулит. Если кому-то, надо, есть сотня других способов занулить регистр. Поэтому сдивгать нужно только на 31 позицию максимум, а значит можно сэкономить на транзисторах делая для схемы только 5 битов втогого аргумента. Или это с какой-то еще более ранней архитектуры пошло.
Нет, не вращение. Просто так работает сдвиг. На самом деле так во всех языках, и об этом много кто не знает. Я например, думал это UB в C++ и никогда так не делал. Но оказывается, это инструкция x86 принимает только 5-6 бит для сдвига.
Допустим у нас битсет на N бит. Разбиваем на M блоков размера K=N/M. Заводим массив вспомогательных данных на M элементов, каждый говорит, заполнено ли там целиком 0, 1, или смотреть биты в битсете с какого-то оффсета, или где храниться список индексов с 1. Все несжатые куски хранятся рядом в одном битсете.
Что-то вроде этого:
int GetBit(int idx) {
int bucket_id = idx / 2048;
switch bucket_type_[bucket_id] {
case kAll0:
return 0;
case kAll1:
return 1:
case kBitset:
return bitset_[bucket_data_[bucekt_id] + idx % 2048]
case kExceptionsAre1:
// В куске не более 10 единичных бит.
return std::find(exceptions_.begin() + bucket_data_[bucket_id],
exceptions_.begin() + bucket_data2_[bucket_id]
, idx) != exceptions_.end();
}
}
В худшем случае bitset_ будет размера со все N бит, но если там много кусков сильно или слабо заполненных, структура занимает мало места.
Только одна проблема - в таком виде структура неизменяема. Если вот эти куски в bitset_ хранить отдельно в куче и вместо одного массива exceptions_ иметь кучу set в куче, то оно даже изменяемо, но производительность там будет такая себе. Там надо будет при изменении бита смотреть, можно ли поменять тип блока.
Ну нет, битовая маска в 8 раз меньше - всего 512mb. Плюс есть всякие хитрые структуры данных, хранящие ее сжатой и все еще с O(1) доступом. Самое тупое - разбиваем на куски, для каждого храним варинты: все 1, все 0, битовая маска в массиве по такому сдвигу, все 0, кроме индексов вон в том массиве исключенимй от сих до сих, все 1, кроме индексов в массиве исключений. В худшем случае, конечно, даже больше памяти займет на вспомогательные данные, но на практике будет куча кусков целиком из 0 или из 1.
Такое себе. Это сработает, не когда все 4 символа больше 64, а когда у них у всех есть какой-то общий старший бит. Код все еще работет корректно, но не соответствует комментарию.
А теперь вопрос - нужна ли программисту математика?
Хорошему - нужна. Это называется математическая база. Не надо вдаваться в дебри высшей математики, но какя-нибудь линейная алгебра, начала матанализа, дискретная математика - самое то. Еще хорошо пройти курс ассемблера, чтобы понимать, что и как работает в компьютере.
А вообще, требовать для понимания своих аргументов пересмотреть какие-то шорты, на которые вы даже ссылок никаких не давали, как будто все не только знают, что это вообще за авторитет, а еще и все его видосики наизусть выучили - такое себе.
Ну это еще можно теоретически объяснить. Можно же там во время звонка поделиться экраном с собеседником?
Вы что-то путаете.
Нет никакой трубы STUN/TURN. STUN (Session Traversal Utilities for NAT) это сервер, который позволяет проковырять дырку в NAT и одновременно узнать свой внешний айпишник. Через него трафик не идет. Используется только для установления соединения. Знать свой айпишник для работы с ним не надо.
TRUN (Traversal Using Relays around NAT) - это сервер для relay трафика. Вот тут уже труба. Но тут опять же никаких своих внешних айпишников знать не надо, вы подключаетесь к серверу и он вам отвечает трафиком, предназначенным для вас.
Вот как это работает в webrtc: Клиент1 и клиент2 за NATами. Клиент1 посылает STUN серверу запрос, получает ответ со своим внешним айпишником и портом. Их сервер видит в адресе отравителя во входящих пакетах. Роутер Клиента1 видит UDP трафик туда-сюда и держит порт открытм. Клиент2 получает эти данные в RemoteOffer, который приложение webrtc должно как-то через свой сервер передать. Клиент2 отправляет данные на этот известный айпишник и порт, NAT пересылает их Клиенту1. Это не работает для NATов, которые назначают порт отдельно для каждого адреса отправителя. Они не сопоставят трафик от клиента2 с трафиком от STUN сервера. Это частая штука на самом деле. В этом случае подключение должно идти через TURN relay.
Можно обойтись без STUN/TURN серверов, если у клиента1 белый айпишник, или администратор сети настроил DMZ, и можно настроить конкретный порт для подключений, что фактически тождественно белому айпишнику. Тогда клиент2 посылает данные на известный белый айпишник и так устанавливается соединение через все NATы перед клиентом2.
Это ваш случай и он частный. Тут нет STUN/TURN вообще, но это возможно только в сети, которую вы контролируете.
Опять же, тут приложению не надо как-то отдельно узнавать свой внешний айпишник во время работы. Или оно его уже должно знать в конфиге вместе с DMZ портом (который вы никаким сервисом в интернете не определите), или это все произойдет автоматически внутри STUN, или оно его видит на сетевом инетрфейсе, если айпишник белый.
Эта история совсем про другое. Вы тут у себя в сети настраиваете свой сервер. Это все не применимо к случаю клиентского приложения, запущенного у клиента в неконтролируемых вами условиях. Как вы вообще будете настраивать DMZ в сети провайдера, за которым сидит клиент?
Нет, это потому что тут разговор про СЕРВЕР STUN, который сам должен быть доступен к подключениям из интернета. А не про клиент, который к серверу подключается из-за NATa.
Конечно, я именно это и написал выше:
Это еще что! Закладка может быть в компиляторе. При чем такая, что она в программы бекдор вставляет, и в исполняемый файл компилятора вставляет сама себя, хоть ее в исходниках и нету. А в дизассемблеры вставляет код, скрывающий себя. В итоге ее нигде не видно если вы только машинный код не читаете, даже если самостоятельно все из выученных наизусть исходников собирать.
Во-первых, DirectX это не только про 3d графику или игры, как вы, наверное, думаете. Там очень много всего буквально для рендеринга текста и картинок.
Во-вторых, зачем именно DirecX а не другое единственное виндовое апи для "рендеринга картинок и текста" GDI вы поймете, когда отключите аппаратное ускорение в настройках хрома. Потому что GDI не аппаратно ускорено.
В-третьих, кроме рендеринга картинок и текста, еще надо декодировать и рендерить видео. Очень много видео. Это тоже DirectX.
В-четвертых, по этим же самым причинам directx использует, например, и Firefox.
Это было бы даже забавно.
Именно так. Жутейшее легаси. Именно поэтому arm процессоры от apple заметно более холодные.
Разработчики MAX нагло врут.
Как один из разработчиков WebRTC утверждаю, что - нет, не требует. Оно само определяет внешний IP, для этого надо указать хотя бы один STUN сервер, который и внешний IP определит и дырку в NATе проковырает, если сможет. А если не сможет, то можно WebRTC еще указать TURN сервер для туннелирования трафика. MAX же обращается не к STUN серверам. Во-первых, у них адреса другие, во вторых STUN протокол видно в дампе трафика.
Руками собирать внешний IP адрес никакого смысла нет. Это совершенно кривое использование WebRTC. Там надо будет еще поизвращаться, чтобы этот внешний IP в него засунуть.
Тут можно было бы еще предположить, что у разработчиков лапки и они не умеют использовать WebRTC. Но это опровергается списком посещяемых адресов. Зачем их столько? Зачем обращаться к заблокированным в россии серверам?
Теория о том, что макс используется как бекдор для роскомпозора для проверки блокировок и детектирования способов их обхода - гораздо более правдива.
Там не сильно много транзисторов надо для неурезанного. Через ИЛИНЕ объединяем все лишние биты, а потом это через И со всеми битами вывода. Когда-то это сделали для экономии, да. Но с тех пор пол века прошло, наверное и можно было бы и сделать по нормальному, но обратная совместимость ломается.
Т.е. это просто ГУИ обертка над FFmpeg, которых тысячи?
Видимо, изначально дизайнеры x86 не думали, что кому-то может понадобиться сдвигать надеясь, что переполнение все занулит. Если кому-то, надо, есть сотня других способов занулить регистр. Поэтому сдивгать нужно только на 31 позицию максимум, а значит можно сэкономить на транзисторах делая для схемы только 5 битов втогого аргумента. Или это с какой-то еще более ранней архитектуры пошло.
Нет, не вращение. Просто так работает сдвиг. На самом деле так во всех языках, и об этом много кто не знает. Я например, думал это UB в C++ и никогда так не делал. Но оказывается, это инструкция x86 принимает только 5-6 бит для сдвига.
Допустим у нас битсет на N бит. Разбиваем на M блоков размера K=N/M. Заводим массив вспомогательных данных на M элементов, каждый говорит, заполнено ли там целиком 0, 1, или смотреть биты в битсете с какого-то оффсета, или где храниться список индексов с 1. Все несжатые куски хранятся рядом в одном битсете.
Что-то вроде этого:
В худшем случае bitset_ будет размера со все N бит, но если там много кусков сильно или слабо заполненных, структура занимает мало места.
Только одна проблема - в таком виде структура неизменяема. Если вот эти куски в bitset_ хранить отдельно в куче и вместо одного массива exceptions_ иметь кучу set в куче, то оно даже изменяемо, но производительность там будет такая себе. Там надо будет при изменении бита смотреть, можно ли поменять тип блока.
Edit: Это называется Roaring Bitmaps.
Ну нет, битовая маска в 8 раз меньше - всего 512mb. Плюс есть всякие хитрые структуры данных, хранящие ее сжатой и все еще с O(1) доступом. Самое тупое - разбиваем на куски, для каждого храним варинты: все 1, все 0, битовая маска в массиве по такому сдвигу, все 0, кроме индексов вон в том массиве исключенимй от сих до сих, все 1, кроме индексов в массиве исключений. В худшем случае, конечно, даже больше памяти займет на вспомогательные данные, но на практике будет куча кусков целиком из 0 или из 1.
Такое себе. Это сработает, не когда все 4 символа больше 64, а когда у них у всех есть какой-то общий старший бит. Код все еще работет корректно, но не соответствует комментарию.
Зачем? PeerConnection сам собирает ICE кандидатов. Надо только STUN сервер ему указать. Можно и к публичным, даже западным, обращаться.
Хорошему - нужна. Это называется математическая база. Не надо вдаваться в дебри высшей математики, но какя-нибудь линейная алгебра, начала матанализа, дискретная математика - самое то. Еще хорошо пройти курс ассемблера, чтобы понимать, что и как работает в компьютере.
Да. Ровно как и водитель не обязан разбираться в устройстве автомобиля. Сейчас. Потому что технологии достаточно зрелые и сложные.
Потому что если там и есть ошибка (процессор неправильно считает), программист ее все равно никак не исправит.
Ну не умеют агенты в хороший код. Поэтому самопроверки в итоге осциллируют между несколькими сломаными по разному клубку макоронин.
Даже один агент сам себя проверяет. Он в любой момент может сгенерировать "Ой, это же не правильно. На самом деле надо вот так:"
Опять же, нет разницы, нет у человека навыков, или его разгильдяйство не позволяет их использовать.
А они были вообще? Может Дима первый был?
Осталось ее эту чуйку формализовать хоть как-то.
А вообще, требовать для понимания своих аргументов пересмотреть какие-то шорты, на которые вы даже ссылок никаких не давали, как будто все не только знают, что это вообще за авторитет, а еще и все его видосики наизусть выучили - такое себе.