MFC 网络聊天+文件传输

[shnaying1945]

这似乎已经是一个很原始的话题了。
学网络编程不久，聊天和传文件的范例都能看得明白。当下要做一个程序，有七百客户端，需要传不少文件，都是音视频类的，也有聊天需求，群聊、私聊，七百用户，您知道的！
1.看到一个例子，里面自己搞个数据结构（结构体），算是数据包头，描述的是数据类型（文件）、数据大小、发送状态，云云，数据包到了客户端再拆包，分析，组合，云云，用的是SOCKET STREAM连接，也就是TCP啦。这例子能随时监听发送状态，得知发送进度，还自带反馈确认机制，挺时尚的样子。
2.又看到个例子，直接上TCP，那边读文件发送，这边接收写文件。完事。
我在想，例子1里的确认机制，TCP不是有么？TCP依然保证可靠传输，何须再确认！这得多低效。我如果用例子2的方案，顶多，少个进度条，少个中途“取消发送”（我主要传送音频，几个M的文件貌似少这个无伤大雅）。但新手，还是劳烦大虾多给点意见。

嗯，到聊天一块。
聊天一块，那么多用户，我首先想到UDP，但是如果发送了出去，对方没接收到这边也没重传确是个问题，至少QQ会告诉你发送失败，要知道发送失败就需要确认，这干的貌似还是TCP的活啊（少了连接）。如果用TCP，七百个TCP连接不放（或许未必只七百个），貌似也不小了，服务器吃不吃得下是个问题。
对于群聊，貌似就是一客户端发来消息，然后服务端转发给其他所有在线客户端，这让我不禁想到ICMP组播攻击（以一个攻击目标为源地址组播ping一个两百台的目标网络，然后目标网络回发200条回复到攻击目标），这赤裸裸的极其相像，只是数据方向相反罢了。首先想到的是组播，但是貌似需要路由器支持啊，据说互联网上不适用。如此，假如采用UDP加确认，那客户端随便一条消息就足以放大1400倍！（以七百客户端算），这让我不知如何是好。
SOCKET用的生疏，还望大家见谅啊，这里问个也许很幼稚的问题。假如不添加包头区分数据类型，如何区分接收到的数据是聊天内容还是文件数据呢？我先想到的是用不同的SOCKET，一个用以聊天，一个用以传文件，但是却不知道在接收端如何区分不同的SOCKET（据说是根据WPARAM，但具体操作却不得知）。如果我想要拥有全局聊天功能兼拥有私聊功能，那或许就需要区分不同用户的SOCKET，服务端能有这个区分吗？还是必须要添加包头，然后在包头添加用户信息呢？

先谢！

[shnaying1945]

看来真不是分多分少，而是人多人少啊。

[这不是鸭头]

一般网络通信都是有自己的通信规约，你说的用不同的SOCKET，一个用以聊天，一个用以传文件，这样你就得在连入的时候表示出不同套接字的作用，或者直接监听不同的端口。不过建议还是有自己的协议，有粘包的时候更好处理。 传文件还是应答式的更好，这样如果某一包出现问题，不会导致整个过程作废。 不管是广播还是组播都是针对局域网来说的，广域网是不行的。只能UDP或TCP。文字传输要是有应得的话，UDP是比较好的选择。

[shnaying1945]

即使是自己添加包头，识别客户端发来的连接也是个问题啊。服务端既然一对多，服务端一个SOCKET用以监听连接，一个SOCKET用以收发数据，他是怎么识别不同的客户端而进行区别对待呢，如果没有什么特别处理，默认的是单点对单点，而且是最后一个客户端的连接才有效的。

[sunnysab]

广域网比较麻烦。 说说局域网的，分析过极域电子教室，实现就是，教师端（就是服务器）保存客户端的列表，统一发消息。如果教师端要“私聊”，直接向那个ip发送。 现在就可以，所有东西服务器中转。端口可以都用一个端口（极域电子教室就是这样的）。 不过话又说回来了，量确实比较大。我担心的是客户端列表保存在客户端有人干坏事

[赵4老师]

不知道有多少前人掉在TCP Socket send(人多)send(病少)send(财富) recv(人多病)recv(少财富) 陷阱里面啊！ http://bbs.csdn.net/topics/380167545

[阿先森]

下面这两篇文章或许能帮到你。 http://www.cnblogs.com/EdmundDwyane/p/3248297.html http://www.cnblogs.com/EdmundDwyane/p/3278641.html 另外还有一个带源码的DEMO http://www.cnblogs.com/EdmundDwyane/p/3461130.html