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

Question

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

Так что для перемещения мыши и щелчка я мог бы использовать класс Robot. У меня есть два вопроса по этому поводу:

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

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

Answer 1

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

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

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

Answer 2

О 2:

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

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

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

Answer 3

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

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

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

Answer 4

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