我有几个运行Windows CE5的智能设备，我们的应用程序是用.NETCF 3.5编写的。智能设备通过集成的GPRS调制解调器连接到互联网。我的客户想要一个远程支持选项，但VNC和类似的工具似乎无法完成这项工作。我发现VNC有几个问题需要它才能运行。首先，它在智能设备上运行时会出现严重的性能问题。第二个问题是互联网提供商有一个防火墙，如果它们不是来自智能设备本身，就会阻止所有传入的请求。因此，我无法启动与智能设备的远程桌面会话，因为请求并非源自智能设备。
我们可以获得自己的APN但是它们太贵了，而且每月的成本对于我们部署的智能设备来说太大了。如果我们能够将开发成本增加到初始产品成本，那对我们来说更经济，因为我们的客户不喜欢高昂的月度成本，而是先付大笔费用。远程支持解决方案还允许我们最小化我们的现场支持。
这就是我们或多或少决定推出自己的远程桌面解决方案的原因。我们有用于在智能设备上捕获图像的代码，并且仅获取自上一周期以来已更改的数据。我们需要的是制作一个像logmein.com这样的通信解决方案（不支持WinCE5），智能设备连接到服务器，然后我们可以将数据流传输给我们的支持人员的客户端。基本上，智能设备启动与我们服务器的连接，并在服务器请求时开始提供屏幕数据。支持客户端连接到服务器并获取可用流的列表，然后选择一个以监听。
考虑到我们必须在智能设备上使用.NETCF 3.5中的解决方案，有关如何做到这一点的任何建议吗？除简单的肥皂网服务外，我们的沟通经验有限。
答案 0 :(得分：2)
既然你要求提出建议，我会建议：
不要重新发明。尽可能地重复使用。您可以使用SSH执行隧道连接，因此在智能设备上通过GPRS建立SSH连接（例如，PuTTY端口或plink，在环路内）;将远程端口转发到本地端口，绑定到SSH服务器的本地地址（127.0.0.1（sshd）：4567 =＆gt; localhost（smart_device_01）：4567）。您的客户端连接到SSH服务器并访问每个设备的分配端口。
话虽如此，这可能不是您正在寻找的答案。下面 - 您可能正在寻找的答案。
根据我对LogMeIn如何工作的分析，您需要创建一个HTTPS或TLS服务器，智能设备将在其中推送数据。我们称之为您的隧道服务器。
您可能希望生成一个新线程，该线程会反复尝试根据您指定的要求与隧道服务器建立连接（出站连接从智能设备到服务器）。使用BEEP / BXXP等协议，您可以封装和复用面向消息或面向流的会话。将BXXP / BEEP包装到TLS中，然后隧道连接到隧道服务器。 BEEP允许您将流复用到一个连接 - 如果您想要内部LogMeIn解决方案的全部功能，您将需要使用类似的东西。
建立连接后，进行新的BEEP会话。使用新会话，告诉隧道服务器您的系统标识信息（设备名称，设备认证签名）。将心跳数据（定期时间戳）写入此新会话。
设置与BEEP控制会话接口的回调（或其他线程）。观察请求服务的消息。当这样的请求进入时，产生所需的线程以从您的自定义远程显示协议复制数据，并通过相同的通道推回这些数据。
这为您的智能设备程序设置了基本前提。您可以根据需要添加功能，以匹配LMI的IT Reach订阅提供的内容（远程注册表，安全隧道Telnet，远程文件系统，远程打印，远程声音......您明白了）
我会假设您知道如何正确保护所有这些内容以便为您的客户端进行身份验证和授权（用户foo是否允许访问智能设备栏？）。
在您的隧道服务器上，启动服务器套接字（侦听入站连接，或从智能设备，智能设备出站连接的角度），以解除多路复用连接和会话。打开连接后，启动BEEP并注册回调/启动线程以等待身份验证/心跳会话。对智能设备执行AAA所需的检查 - 是否允许这些设备，是否已知，成本是多少等。您的隧道服务器代表您的智能设备转发数据。对于每个BEEP会话，在AAA程序成功后，将名称（设备名称）附加到BEEP会话;失败时，关闭连接并让AAA机制知道（阻止攻击者）。您的隧道服务器还应设置与前端交互所需的内容 - 也就是说，它应该具有与BEEP交互的代码，以便为远程显示数据解复用流。
在您的前端服务器上（可以与隧道服务器相同），安装AAA例程 - 检查用户是否已知，是否允许用户，应该向用户收取多少费用等。传递所有检查，从前端服务器到隧道服务器建立安全连接。获取隧道服务器知道允许用户访问的设备名称。此时，您应该能够从隧道服务器获取基于设备名称的“纯文本”流。将此流转发回用户（例如，通过TLS，或通过TLS上的BEEP再次），或者为远程显示客户端发送所需的配置，以使用所需参数连接到隧道服务器以访问远程显示协议的流。