用java实现我自己的远程桌面
我正在尝试用java实现我自己的远程桌面解决方案。使用套接字和 TCP/UDP。 我知道我可以使用 VNC 或其他任何东西，但我想做的是学校的作业。
因此，为了移动鼠标并单击，我可以使用 Robot 类。我对此有两个问题：
发送视频怎么样？我知道 Robot 类也可以捕获屏幕，所以我应该按顺序发送图像并在连接的另一端按顺序显示吗？这是实现远程桌面的最佳方式吗？
我应该使用 TCP 还是 UDP？ 我认为 UDP 会更难实现，因为我必须弄清楚哪个图像在另一个图像之后。
I am trying to implement my own remote desktop solution in java. Using sockets and TCP/UDP.
I know I could use VNC or anything else, but its an assignmentwork from school that I want to do.
So for moving the mouse and clicking I could use the Robot class. I have two questions about this:
What about sending the video? I know the Robot class can capture the screen too, so should I just send images in a sequence and display in order at the other side of the connection? Is this the best way to implement remote desktop?
Also should I use TCP or UDP?
I think UDP would be harder to implement since I will have to figure out which image comes after the other.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您尝试做的事情将会起作用，但速度非常慢。在通过网络发送图像之前，必须对其进行压缩。压缩之前，应减少颜色数量。此外，仅应发送自上次更新以来已更改的图像部分。
传输鼠标坐标时，仅当新的鼠标位置距最后位置超过 x 像素或经过 y 秒时，才会发生更新。否则，您会在鼠标位置上花费大量流量，以致没有空间容纳图像。
UDP 将是这里最好的解决方案，因为它对于视频流来说是最快的（这就是您正在有效做的事情）。
What you are trying to do will work, but incredibly slow. The images must be compressed before you send them over the net. Before compressing, the number of colors should be reduced. Also, only the portions of the image which have changed since the last update should be sent.
When transferring mouse coordinates an update should only occur if the new mouse position is more than x pixels away from the last position away or a number of y seconds is over. Otherwise you spend so much traffic for the mouse position that there is no room for the images.
UDP will be the best solution here, since it is fastest for video streaming (which is what you are effectively doing).
关于 2：
UDP 会困难得多，因为它是基于数据报的协议，一次可以发送的数据量受到限制；您不太可能将整个图像放入单个数据报中。因此，您将不得不使用差异/部分更新，这很快就会变得复杂。
然而，TCP 是基于流的并且仅按顺序传送数据。如果中间的数据包消失并需要重新发送，则所有后续数据包都需要等待，即使它们已被目标机器接收。这会产生延迟，这在交互式应用程序中通常是非常不受欢迎的。
因此，UDP 可能是您的最佳选择，但您不能围绕一次可以发送整个图像的假设来设计它，您需要想出一种仅发送部分图像的方法。
About 2:
UDP would be much harder, since it's a datagram-based protocol there are limits on how much data you can send at a time; it's not very likely that you are going to be able to fit entire images into single datagrams. So, you're going to have to work with differential/partial updates, which becomes complicated pretty quickly.
TCP, however, is stream-based and only delivers data in-order. If a packet in the middle disappears and needs to be re-sent, all following packets need to wait, even if they've been received by the target machine. This creates lag, which is often very undesirable in interactive applications.
So UDP is probably your best choice, but you can't design it around the assumption that you can send whole images at a time, you need to come up with a way to send just parts of images.
基本上，视频是按秒显示的图像（帧）序列。您应该在带宽允许的范围内发送尽可能多的内容。
另一方面，发送原始图像是没有意义的，您应该尽可能地压缩它，并且绝对要考虑在此过程中丢失大量分辨率。
你可以看看这个关于图像压缩的问题，如果你压缩得足够多，你可能有一个生动的视频。
Basically a video is a sequence of images ( frames ) displayed by second. You should send as much as your bandwidth allows you.
On the other hand, there is no point to send the raw image, you should compresss it as much as you can, and definitely consider lose a lot of resolution in the process.
You can take a look at this SO question about image compression if you compress it enough you may have a vivid video.
如果使用 Google Protocol buffer 或 Apache thrift 会更好。您将发送更小的二进制数据 - 这样，您的软件将运行得更快。
It will be better if you use Google Protocol buffer or Apache thrift. You will send binary data which will be smaller - by this, your software will work faster.