在写一个桌面监控程序，客户端每隔100毫秒会和服务器发送一个截图文件。
现在的问题是所有的文件都通过一个tcp连接发送，还是一个文件新建一个连接？
如果每个文件建一个连接，100毫秒一个连接是不是太频繁了?
如果所有文件都是一个连接的话，服务器要知道文件的大小，再开一个新端口专门接受文件的大小。
所有的文件内容都是在一个连接中接收的，再根据接收到的大小去一个个分割byte数组。
这个思路对么？
我的思路是这样的,一个固定端口(客户端,服务器端各一个),用来进行c/s对话的,客户端想服务端发送文件信息(一段固定格式字符串),包括(文件名,文件大小,其他信息,用来告诉服务器端你想要干嘛),服务器端接收到信息后进行解析,然后新开一个监听端口,并把此端口信息发送给客户端(通过固定的对话端口),客户端通过对话端口接收到信息后,连接服务端的临时传送端口,传送文件.文件传送完毕后,这个端口就关闭了.服务器端建议使用多线程新开端口.
不对，不解释。
我的思路是这样的 不用临时的去开传输文件端口 就开始的时候客户端去连接服务器 后面传输数据的时候 在数据包的前面定一些格式 比如：文件名+数据长度+数据内容 文件名+数据长度所占用的字节长度为定长 服务器再进行相应的解析
kinurs给的思路还是不错的，也可以每个文件建一个连接，但是在服务器端建立连接池来控制连接数量，连接池的大小可以根据具体测试过程中获取的数值来调节，达到一个性能最佳的数值。
这桌面监控的方案真有创意， 为什么不取到每秒24帧， 然后再做个播放软件就可以当电影看了
提示：在1GBps 网络环境下，新创建一个TCP 连接，三次握手消耗的时间大概在25ms 左右。
传输内容，如果考虑效率就用二进制，自己构造协议就行。也不需要自己去想，网上有现成的开源的包，能够根据你的要求构造相应的协议和消息体的。