во-первых это не постулат, а ваше предположение. почувствуйте разницу.
во-вторых как вы уже поняли, маленький размер запроса не гарантирует того, что он будет передан за один сетевой кадр. типичного размера буфера для всех типов соединений нет. поведение отправки определяется алгоритмом Нагла, а MSS в разных ОС уже определяется по типу соединения и его MTU. для сокета с низкой задержкой алгоритм Нагла следует отключить.
в-третьих TCP-соединение не берётся из ниоткуда. оно начинается с тройного рукопожатия — соответственно это два пустых пакета туда и один обратно. совсем другое дело если сервер поддерживает Keepalive и соединение уже было установлено.
этого всего я в ваших рассуждениях не увидел о быстрой передаче не увидел
нет, менкодер ещё картинку накладывает, я этим занимался как-то. но по-моему только статическую. как насчёт выведения видео с камеры на экран, наложения надписей и картинок с камеры поверх прозрачным окном и непрерывным дампом писалкой экрана?
тогда так. все приложения гоним с одного интерфейса как обычно, но через линуксовый роутер (которым, возможно, может послужить сам гипервизор). если ядро маршрутизатора, который будет стоять по пути, выше чем 2.6.10 и IP-адреса исходные идут диапазоном подряд, то можно сделать SNAT просто на диапазон адресов и ядро само раскидает раунд-робином по адресам коннекты. если исходные адреса идут не подряд, потребуется ядро версией младше 2.6.10, там можно несколько диапазонов вписать
раскройте немного тайну, какая стоит конечная цель? если сторона клиентская, то видятся такие решения:
a). раскидать исходные адреса по разным интерфейсам, клиентское ПО нацеливать на разные левые «адреса сервера» и к этим адресам прописать маршруты через разные интерфейсы — получатся разные исходные IP. на роутере по пути сделать DNAT всех липовых адресов в сторону реального конечного адреса сервера, на линуксе правило так и называется — DNAT
б). метить как-то пакеты на клиенте в зависимости от процесса и на роутере делать им SNAT по критериям разных меток. чем метить пока сходу не придумал
линукс не юникс, а макос трудно поставить, чтобы всё заработало. поэтому после макоса опенсолярка и фря, пожалуй, самые распространённые юниксы на десктопах
как раз таки наоборот, в 11.04 постоянно приходится юнити перезапускать, то панель зависает в открытом положении, то окна куда-то теряются из панели. в федоре 15 всё нормально и очень удобно с этим
добавлю, пожалуй, что вам возможно будет проще всё-таки использовать иксы, но без окружения рабочего стола и менеджера окон. тогда и ресурсов получится немного и зависимостей мало
unconnected, по высказываниям «это не то, это не так, этот язык не подходит для того» сразу видно уровень подготовки, поэтому я такие вещи говорю людям и напрямую без опаски