Реализация моего собственного удаленного рабочего стола в java

Я пытаюсь реализовать свое собственное решение для удаленного рабочего стола в java. Использование сокетов и TCP/UDP. Я знаю, что я могу использовать VNC или что-то еще, но это назначение из школы, которое я хочу сделать.

Итак, для перемещения мыши и нажатия я могу использовать класс Robot. У меня есть два вопроса:

  • Как насчет отправки видео? Я знаю, что класс Robot также может захватывать экран, поэтому я должен просто отправлять изображения в последовательности и отображать по порядку на другой стороне соединения? Это лучший способ реализовать удаленный рабочий стол?

  • Также следует использовать TCP или UDP? Я думаю, что UDP будет сложнее реализовать, так как мне придется выяснить, какое изображение появляется после другого.

Ответ 1

То, что вы пытаетесь сделать, будет работать, но невероятно медленно. Изображения должны быть сжаты, прежде чем отправлять их по сети. Перед сжатием следует уменьшить количество цветов. Кроме того, только те части изображения, которые изменили с момента последнего обновления, должны быть отправлены.

При переносе координат мыши обновление должно происходить только в том случае, если новая позиция мыши находится на расстоянии более х пикселей от последней позиции или закончилось несколько y секунд. В противном случае вы тратите столько трафика на позицию мыши, что нет места для изображений.

UDP будет лучшим решением здесь, поскольку он является самым быстрым для потоковой передачи видео (что вы эффективно делаете).

Ответ 2

Примерно 2:

UDP будет намного сложнее, поскольку в протоколе, основанном на дейтаграмме, есть ограничения на то, сколько данных вы можете отправлять за раз; это не очень вероятно, что вы сможете разместить целые изображения в одиночные датаграммы. Таким образом, вам придется работать с дифференциальными/частичными обновлениями, что довольно быстро усложняется.

TCP, однако, основан на потоке и только обеспечивает доставку данных в порядке. Если пакет в середине исчезает и его необходимо переслать, все последующие пакеты должны ждать, даже если они были получены целевой машиной. Это создает отставание, которое часто очень нежелательно в интерактивных приложениях.

Таким образом, UDP, вероятно, ваш лучший выбор, но вы не можете его спроектировать в предположении, что вы можете отправлять целые изображения за раз, вам нужно придумать способ отправки только части изображений.

Ответ 3

В основном видео - это последовательность изображений (кадров), отображаемых вторым. Вы должны отправлять столько, сколько позволяет ваша полоса пропускания.

С другой стороны, нет смысла посылать необработанное изображение, вы должны сжимать его столько, сколько сможете, и определенно считаете, что потеряете много разрешения в этом процессе.

Вы можете взглянуть на этот вопрос о сжатии изображений, если вы достаточно сжимаете его, чтобы иметь яркое видео.

Ответ 4

Лучше, если вы используете буфер протокола Google или арифметику Apache. Вы отправите двоичные данные, которые будут меньше - тем самым ваше программное обеспечение будет работать быстрее.