Wexter, перечитал 3 страницы Гугла. Так и не нашёл подтверждения вашим словам, хотя они звучат логично в контексте ADDR:PORT. Не могли бы вы написать ответ с ссылками (или ссылкой), подтверждающими ваши слова?
pfg21, я был бы рад реализовать сообщение через тот же QUIC, но я ограничен требованиями к проекту. Проект обязан гарантировать пользователю безопасность, и как бы я не пытался объяснить, что UDP тоже может гарантировать доставку сообщений, я не могу победить предубеждение.
Wexter, я где-то описался выше? Естественно, каждый сервер имеет один порт. Но проблема то с клиентской точки зрения. Каждый раз, когда я подключаюсь к другому серверу, я должен занять порт. Порты в этой схеме кончаются у клиента.
Сергей Соловьев, в идеале, конечно, поставить один суперкомпьютер с процессором на где-то миллион ядер и с где-то 70 ТБ оперативной памяти и шардировать приложение по одному потоку на каждое ядро, где каждый поток самодостаточен. Но в реальности приходится шардироваться на нескольких машинах. Мне очень интересно узнать, как реализовать кластер быстрее, чем через общение каждой машины с каждой. Но поддержание открытых соединений стоит мало, а использования дополнительных компьютеров в этой схеме порождает слишком много дополнительных IO операций, что дороже.
Если вы можете хотя бы дать намёк, как это сделать быстрее, я буду благодарен.
pfg21, мне тяжело принять такое решение. Вариант с выделением дополнительно компьютера увеличивает задержки и уменьшает пропускную способность, причём очень сильно. С другой стороны, я не вижу способа обойти ограничения сейчас. Поэтому я обратился сюда, чтобы попробовать найти способ обойтись без столько медленного решения.
Сергей Горностаев, я не могу применить такое решение, потому что не знаю, какие функции создаст пользователь. Я могу разве что описать одну общую функцию, которая принимает срез байтов и ссылку на структуру.
Василий Банников, я компилирую приложение, которое слушает TCP. Пользователь описывает функции в файле (скорее всего lua) и запускает приложение. Когда пользователь вызывает определённый endpoint с названием функции и телом запроса, приложение должно найти эту функцию, передать туда тело запроса и ссылку на структуру (или саму структуру, но сомневаюсь, что могу передавать структуры из Rust в другие языки), более того, функция может пробовать вызвать скомпилированные методы у этой структуры.
zzmaster, Вы правильно поняли. В голом React можно (через useContext, если не ошибаюсь), но так делать не принято, так как гораздо удобнее использовать готовые стейт-менеджеры (которые работают поверх useContext).
Василий Банников, Спасибо за объяснения. Честно уже год считал, что в Docker всё быстрее работает (наблюдения подтверждали эту теорию, пока не начал работать с диском).
darst, я был бы очень рад, если бы это оказалось правдой. Но этот log никогда не будет выведен (я проверил). Как я написал ранее, мы никогда не попадём здесь в это условие.
darst, это я понял. Я не могу понять, почему после прибавления size offset становится больше l. Если это допустить, то ваша теория полностью верна, однако, если я правильно понимаю свой код, в худшем случае мы получим, что offset будет равен l.
darst, я всё ещё не понял, как offset становиться больше l, если have равен size. По идеи, в худшем случае мы получим, что offset будет равен l, тогда have станет равным 0 и мы попадём в выше приведённый код.
darst, я всё ещё не понял, что вы имеете в виду. Я перечитал весь код связанный с have и не нашёл ничего плохого в том, что have может быть равным size. В этом случае мы корректно обработаем ответ, а на следующей итерации цикла have будет равен 0 и мы прочитаем ещё из соединения.
calculator212, Это я уже обнаружил. Проблема в том, что я так и не понял, при каких условия offset становится неправильным. Я проверил каждое изменение offset и не нашёл ошибку.
