turn и stun сервера немного разные вещи. Turn может выполнять функции stun для поиска прямого соединения, но как правило это работает редко и turn выполняет свою основную функцию (весь медиа трафик пропускает через себя) и это нужно не только при установке соединения но и на протяжении всего соединения. Всякое бывает и кейсы применения разные, может в вашей ситуации и возможно прямое соединение, но такое бывает редко.
p2p в достоинствах это хорошо, но стоит учитывать что такой подход работает только при очень низком числе соединений, дальше только сервер (sfu и прочие технологии). И да даже в ситуации установки связи между двумя устройствами, когда действительно нужно соединение клиент-клиент это почти никогда не будет работать напрямую без turn серверов в публичных сетях, а это уже тоже не совсем p2p.
А что собственно плохого? Я например прекрасно понимаю что api лучше писать скажем на go, ещё большей производительности можно добиться на более низкоуровневых языках, есть бенчмарки, это всем известно. Вот у нас в компании api пишут на go и не применяют orm, пишут sql для производительности, работает хорошо и быстро. Полтора года назад решили поднять сервис, там и фронт и бэк (несколько) с бд разными и брокером. Так вот в одного разработчика на фронт и api все ушло около месяца. Фронт на vue, api nestjs с orm и вообще всем что ускоряет и упрощает разработку. Релизы, довольно функциональные, пишутся за пару дней - неделю. И того стоимость сервиса месяц ЗП одного разработчика. Я прекрасно понимаю что если сделать все хорошо и идеально на правильных инструментах работать оно будет сильно быстрее. Но какая бизнесу разница, если на сервере нагрузка по итогу с 10% на самой дешёвой тачке. А клиенты есть и уже год платят деньги. А все хорошо, идеально и на правильных инструментах, это найми фронта, найми бекендера с отдельным стеком, наладь синхронизацию между ними, пиши sql чистые под каждый кейс и ещё много всего. Рентабельность такого решения выйдет на порядок хуже. В заключение, это я все к тому что писать все на js конечно не надо, но кейсы когда это банально сильно выгоднее бизнесу есть.
В своей жизни множество раз встречал людей которые "разбираются" в своем деле и на полной уверенности давали ложные знания, включая образовательные программы, которые тоже кажутся вполне логичными, но после читаешь тот же вопрос ещё в 10 источниках и понимаешь как и что работает на самом деле. Поэтому это не совсем проблема именно ИИ, ровно как и человек может получить ложную информацию и распространять её с уверенностью что она истина потому как получил её от человека с корочкой по данному вопросу, так и ошибки ИИ могут быть следствием выборки
ps. По поводу опасного колдунства считаю, что любой код, который не является общепринятым и не используется большим числом проектов и особенно если нет полной ясности как он работает(когда его написал не ты сам или до конца не понял как оно работает), выглядит как опасное колдунство. Возможно лучшее документирование и пояснение принципов работы поможет исправить эту ситуацию
Спасибо за комментарий, да, в имени файла опечатка, отладка в devtools в dev режиме будет точно такой же, т.к. ничего не собирается, а плагин добавляет несколько файлов в основной поток и адаптер в поток воркера, а сами файлы не изменяет вообще, отладку в prod режиме пока не проверял, но она как вы правильно заметили побольшей части зависит от source map, все кейсы пока сильно не проверял, но source map самих файлов должны сохраниться т.к не изменяются, plugin api даёт возможность предоставить source map для изменений, этот вопрос в ближайшее время проверю тщательнее
Я бы еще добавил упоминание того что например chrome браузер может делать одновременно до 6 соединений на вкладку и даже если делать promise.All то запросы будут выполняться пачками по 6 штук
turn и stun сервера немного разные вещи. Turn может выполнять функции stun для поиска прямого соединения, но как правило это работает редко и turn выполняет свою основную функцию (весь медиа трафик пропускает через себя) и это нужно не только при установке соединения но и на протяжении всего соединения. Всякое бывает и кейсы применения разные, может в вашей ситуации и возможно прямое соединение, но такое бывает редко.
p2p в достоинствах это хорошо, но стоит учитывать что такой подход работает только при очень низком числе соединений, дальше только сервер (sfu и прочие технологии). И да даже в ситуации установки связи между двумя устройствами, когда действительно нужно соединение клиент-клиент это почти никогда не будет работать напрямую без turn серверов в публичных сетях, а это уже тоже не совсем p2p.
А что собственно плохого? Я например прекрасно понимаю что api лучше писать скажем на go, ещё большей производительности можно добиться на более низкоуровневых языках, есть бенчмарки, это всем известно. Вот у нас в компании api пишут на go и не применяют orm, пишут sql для производительности, работает хорошо и быстро. Полтора года назад решили поднять сервис, там и фронт и бэк (несколько) с бд разными и брокером. Так вот в одного разработчика на фронт и api все ушло около месяца. Фронт на vue, api nestjs с orm и вообще всем что ускоряет и упрощает разработку. Релизы, довольно функциональные, пишутся за пару дней - неделю. И того стоимость сервиса месяц ЗП одного разработчика. Я прекрасно понимаю что если сделать все хорошо и идеально на правильных инструментах работать оно будет сильно быстрее. Но какая бизнесу разница, если на сервере нагрузка по итогу с 10% на самой дешёвой тачке. А клиенты есть и уже год платят деньги. А все хорошо, идеально и на правильных инструментах, это найми фронта, найми бекендера с отдельным стеком, наладь синхронизацию между ними, пиши sql чистые под каждый кейс и ещё много всего. Рентабельность такого решения выйдет на порядок хуже. В заключение, это я все к тому что писать все на js конечно не надо, но кейсы когда это банально сильно выгоднее бизнесу есть.
Можно просто поставить минус перед формулой, это не запрещено
В своей жизни множество раз встречал людей которые "разбираются" в своем деле и на полной уверенности давали ложные знания, включая образовательные программы, которые тоже кажутся вполне логичными, но после читаешь тот же вопрос ещё в 10 источниках и понимаешь как и что работает на самом деле. Поэтому это не совсем проблема именно ИИ, ровно как и человек может получить ложную информацию и распространять её с уверенностью что она истина потому как получил её от человека с корочкой по данному вопросу, так и ошибки ИИ могут быть следствием выборки
Вот так
Ссылка должна работать если её вставить как ссылку а не как текст
А о чем статья? Эта информация присутствует в учебниках по материаловедению более 50 лет
Вы пытаетесь изобрести sfu? просто возьмите что-то готовое, все уже есть, как говорится самый лучший совет по написанию sfu, не пишите свой sfu
На счет работает, согласен, но на счет разрабатывается, прям спорно мне кажется
ps. По поводу опасного колдунства считаю, что любой код, который не является общепринятым и не используется большим числом проектов и особенно если нет полной ясности как он работает(когда его написал не ты сам или до конца не понял как оно работает), выглядит как опасное колдунство. Возможно лучшее документирование и пояснение принципов работы поможет исправить эту ситуацию
Спасибо за комментарий, да, в имени файла опечатка, отладка в devtools в dev режиме будет точно такой же, т.к. ничего не собирается, а плагин добавляет несколько файлов в основной поток и адаптер в поток воркера, а сами файлы не изменяет вообще, отладку в prod режиме пока не проверял, но она как вы правильно заметили побольшей части зависит от source map, все кейсы пока сильно не проверял, но source map самих файлов должны сохраниться т.к не изменяются, plugin api даёт возможность предоставить source map для изменений, этот вопрос в ближайшее время проверю тщательнее
Я бы еще добавил упоминание того что например chrome браузер может делать одновременно до 6 соединений на вкладку и даже если делать promise.All то запросы будут выполняться пачками по 6 штук