怎么样利用socket实现Server向Client发送数据，包括实时发送的数据和非实时发送的数据

码拜

9年 ago

各位菊苣好…
在写程序的时候遇到个问题：
现在有个服务器端(Server)，会实时向客户端(Client)发送数据。实时数据一共分为4个类型，因此分为4个长度为1440的byte类型数组，每隔1s向客户端发送一次数据。这个当前已经实现了，利用的就是socket的send、receive函数。
现在希望在服务器端添加一个向客户端发送文件的功能。虽说是文件，但实际上只是一个包含5300个数据的txt文件。现在不知道怎么把这两种通信结合起来，还望各位菊苣指点…

解决方案

文件读取到byte[]后就和数据没什么不一样了，都是byte[]数据，一样的发送一样的接收，客户端收到byte[]数据后把byte[]转为文件就完成了

你的协议里面应该有说明接收长度吧，把文件读出来，一次性发送，os会自动为你分包的，你只需要在本人协议中指明包长度即可

假如你根本识别 byte[ ] 是干什么的，那么你当然可以随便说“本人实现了”，原因是这是最低层的传输概念。这就好像只认识什么可以吃的人，跟认识本人爱吃什么不爱吃什么的人，一个是最低的、另一个才是正常人。
要传输本人的信息，那么那你的信息就区分几百种。一个设计者需要设计“信令格式”，从而程序可以把 .net 对象序列化为不定长的 byte[ ]，另一端再反序列化为 .net 对象。你至少有几十个自定义的 .net 对象类都可以收发、解析。到了这一层，你才应该说“这个当前已经实现了”。

你的意思是不是现在接口已经写好了，你只能使用？
那么，有4个数据类型，你可以将其中一个作为总长度，一个作为唯一ID（标识文件，分多个帧发出ID相同，这样就可以在客户端进行组合了），一个作为文件名，剩下的一个作为文件内容，文件拆分成多个段，分成多个帧发出去。
在客户端接收到后，根据文件总厂，文件ID，文件名几个信息，对收到的帧进行恢复

你还不如约定服务端发个指令，让客户端主动来拉的方式，服务器推让客户端怎么组织成一个文本啊

引用 11 楼 aasdasdasdqwe 的回复:

Quote: 引用 9 楼 sp1234 的回复:
程序设计师，一说到设计，他必定是从最恰当的那个高度、层次来说的。虽然每一个人可以有不同的习惯，但是假如你把别人所说的关于设计的事情都理解为你本人的“要把文件拆分成若干个byte[] 类型的数据，分别发送到客户端，然后再在客户端组合起来”，这就好像是别人跟你谈“吃什么好”而你理解为“吃什么能勉强活着”，就好像别人跟你说怎么样搞建筑而你理解的是怎么样开石头和泥巴，虽然你说的是永远都“正确”的话，但是没有一下子搞懂那个所需要的技术“层次”到底在哪里。
你要围绕着正确的思路去设计，不要总是从最底层去理解。

首先谢谢您的指点，感觉本人确实整体概念不强…
本人之所以老是在说底层的byte[]数组，是原因是本人这个问题中虽说涉及到txt，但是实际上取的还是里面的数据点。本人计划将里面的全部数据值都转换成byte类型然后塞到数组里去。
然后本人解释下本人现在纠结的点，似乎之前完全没说清楚…
本人之所以老强调拆分成byte[]数组，是原因是本人现在不知道本人到底应该：
（1）把5300个数据点（也就是5300*2=10600个byte值）放在一个完整的Byte数组里还是
（2）把他们按照每个byte数组长度1440进行拆分。每个数组首端附上标志位，进行次序的定位。然后在客户端进行文件的新建、数据包的整理。
第一种方案肯定比较简单，但是原因是前面说到同步通讯过程中的数组长度为1440，所以本人不确定能不能用第一种方案。
本人对Socket编程了解的还是比较少…假如说的有什么很蠢的地方，还请见谅…

为什么限定同步通信长度为1440，你这个tcp又不是udp，限定长度干什么。设计基于tcp的信令最通用的方法就是告诉接收方要接收的长度，例如规定前两个字节表示后续应该接收多少个字节，接收端只需要先读取这两个字节计算出后续应该接收的长度，再去把后面的取出来就算完成一条通信了。而你在发送的时候也不用分组，放在一个byte【】发过去，只要在协议里表明正确的长度即可。