TCP协议下，有关 点对点传输二进制流文件 设计思想的若干问题

Question

客户端发送命令给服务端，要求服务端接收文件，服务端返回一个值告诉客户端准备就绪。此时，客户端从要传送的文件中读取4k，发送给服务端，服务端接收后返回一个值告诉客户端，客户端继续读取4k发送。以此类推，最后客户端发送一个命令给服务端，告诉服务端文件发送完毕。服务端再次返回一个响应值。整个过程完毕。问题1：请问这个思路是否正确，若正确哪里需要改进，若不正确应该如何构思？
问题2：每次发送4k是否合适，还是要看网络状况重新定大小？
问题3：怎么样避免客户端发送过快，服务端来不及接收。或者客户端发送过慢，浪费带宽的问题？
问题4：服务端怎样区别客户端发送过来的是数据还是命令？每个问题25分，期待大家给小弟指点迷津，谢谢

Answer 1

1.可以，但是没有必要每4k都要发送多一个命令吧，文件读完没有你的程序肯定可以知道的
2.个人觉得还可以了，（建议1024字节）
3.不懂
4.改写TCP结构，你可以自己构造一个结构，里面有一个用来存储命令的，这样就可以了，刚好就跟1.对应起来。

Answer 2

1.类是ftp上传方式是么？那么觉得首先要对文件分块，先告诉服务器你上传多少块，每块大小，这些要在协议里面有所体现。当服务器发现那个块错误的时候，也可以直接要这个块。
2.大小可变，通过上面的意思，有客户端定义块大小。
3.客户端发送过快，这个不会，因为，每次服务器都进行了相应，服务器部分来完成负荷控制。一回一应，应该不会浪费吧。
4.命令和数据是好协议区分的协议一般包含
头，控制码，长度，数据，校验，尾
入
FE,0c,00,00,CRC,18
头 控 长度  校验 尾
以上
FE是头，0C是控制码
如下：
01，读命令
02，写命令
03，错误
04，成功！！
这个就可以区分了当然具体协议还要复杂点 ，你可以参看一些协议方面的书籍参考。

Answer 3

个人有以下看法：1、如果是做成SC式的（服务器和客户），在这儿指的是服务器要同时联接多个客户（至成百上千甚或万个），的情况下，本人建议：每个客户使用1个SOCKET和主机相联。当客户端发出特定代码时比如：FF 00 FF 00 F0 F0 F0 F0 FF 00 FF 00 F0 F0 F0 F0（01）表示成功。FF 00 FF 00 F0 F0 F0 F0 FF 00 FF 00 F0 F0 F0 F0（02）表示错误等。应注意的是，因为都是二进制流，特定代码不能过短，以防万一和正常数据流重码！2、如果是做成客户和客户式的，也就是说，是客户之间的相互通信，本人建议一个传送点使用两个通道。一个通道用来传送数据，另一通道用来传送认证信息。另外，为了数据的正确性，还可加入校正数据。校正数据可以通过传输数据累积之和的后几位（或全部）做。至于4K是否合适，本人以为，从最好效果来说，应视网络来定，但是一般情况下，应该比较合适，如果加入网络情况测定功能块，那又会让你累好多，程序可能也会慢，似乎得不偿失，当然，如果楼主技术和时间够的话，建议加上，并让其成为可选。3、“怎么样避免客户端发送过快，服务端来不及接收。或者客户端发送过慢，浪费带宽的问题？”在SOCKET方式下，此问题不必考虑。点对点方式下，不可能出现客户发送过快的问题。至于浪费带宽，那就更无从说起，只能是因为网络慢没法快起来。其实，在SOCKET的联接过程中，本身它就带有一定的数据自校功能，当然为了更保险，大部分人还是会自个加写自校的。

Answer 4

to 楼上，您的协议不敢苟同，本人尚未看到过
FF 00 FF 00 F0 F0 F0 F0 FF 00 FF 00 F0 F0 F0 F0（01）表示成功。FF 00 FF 00 F0 F0 F0 F0 FF 00 FF 00 F0 F0 F0 F0（02）如此协议
标志码没有必要像你这样长太浪费，如果都是pc还好，那么有一方面是采用gprs无线方式呢
1k 3分钱呢记得哦，我们是有校验的,16位的crc校验，不怕误码...
特征码，重复问题在tcp应用层也不用太在意，tcp会自动将发送来的包组合，一般不分包
即使分，那么我们还有长度界定，数据块始终是包含在控制码之中，所以没必要大动干戈
而且也不适合理解。网上的协议格式很多啊，楼主去查查就可以了。