Там же суть не в том, чтобы писать асинхронный код, а в том, чтобы в том числе и метод socket.accept() был неблокирующем, а такие вещи должны быть написаны в коде сервера с использованием различных сисколлов вроде kqueue, epoll. Писать это самому равносильно написанию сервера с нуля
Есть единый сервер, есть множество клиентов, для каждого клиента внутри TLS генерируется симметричный ключ (алгоритм шифрования RC4), затем по UDP этот ключ используется. Как TCP(TLS), так и UDP взаимодействие происходит на одном сервере, даже внутри одного процесса
Защищённое UDP-соединение применяется (в данном случае), для real-time приложения, где каждая миллисекунда на счету, не стал про это говорить в вопросе для краткости.
Ну и вообще, насколько мне известно, VPN это более комплексное решение, воздействующее на весь трафик целиком, а не лишь на трафик одного приложения. По крайней мере, например, Steam и Blizzard не используют его для secure части своего протокола
У меня было следующее предположение: если потоку T1 нужно было бы прочитать файл, то в среднем было бы 1 перемещения головки диска (если конечно файл не очень большой и никому в процессе не понадобится диск). А если потокам T1 и T2, нужно будет прочитать по файлу, например, F1 и F2 соответственно, то треды по по очереди дёргали головку диска, из-за чего было бы много её перемещений.
Я так понимаю, это и называется линейное и случайное чтение, как Вы упомянули ?
Ну, RTT это время между отправкой пакета и принятием ack'а для него. А там говорится про время между двумя последовательными полученными пакетами, это не RTT
Drno, ну да, много мелких удаляются намного дольше, чем один большой, но там это связано с тем, что просто головке диска приходится больше физических перемещений делать
Drno, ну, вообще звучит логично, ведь роутеру нужно перенаправить куда-то пакет, и чем больше их (пакетов), тем больше он будет выполнять своей целевой работы
