求：大文件传输程序（比方说传电影）

参考
http://www.codeproject.com/KB/IP/SocketFileTransfer.aspx

你可以看我另一个帖子，附上代码了，不过还没解决问题
http://topic.csdn.net/u/20091022/15/932432b6-af40-45e4-845c-9de2c60355ad.html

试试连续两次发送时，中间加个Sleep(2毫秒)（或再增大）延时；

如果是UDP，应该给每个包编号，接收端按编号组装。
如果是TCP，应该不会有这个问题~~

http://topic.csdn.net/u/20091022/15/932432b6-af40-45e4-845c-9de2c60355ad.html
这里有主要的代码是tcp的现在也在看这方面的资料。调试的话不好调的啊，都是发送了一段时间出的问题。
不可能断点跟踪的啊

接受文件的那端一直recv,直到接收到的字节数和你所发送的文件大小相同。

看了上面的演示代码，和我的区别就是发送和接收的时候设了保护，根据函数返回值
做了判断，我想问题也应该是出在这里，毕竟按1000字节一次次的传，传大文件是要
传几十万次的，socket函数出问题的概率也大了，不过就算少传了或少读了怎么程序
出错呢？应该是最后接收的文件有问题吧！谁能解释下？解释出来的就结贴给分了。

可不可能出现这种情况：
struct A
{
    int a；
     BYTE buf[1000]；
}A  a[3];当我传送数据的时候，a[1]到达了  a[2]的前一部分到达了  a[3]到达了， a[2]的后一部分
到达了。  会出现这种情况吗？？（每次都是发送一个A结构）

这种同样大小的数据传送是否出现后发先至没试过，但确有不同大小时，当前一部分大而后一部分小时常出现后发先到的情况。另外，对于这种情况你接收应该先按收到的int a排列存起来，等全部收齐或收到连续的NO时再连接文件吧。

TCP 会粘包的, 接收一次的数据大小并不是发送方一次的数据大小

void CFileRDlg::SendData(CMysock *sock)
{
int sendcount = 0;
int count = SIZE_CFileData;  // 结构体的大小,即一个包的长度
do
{
sendcount = sock->SendMsg(&m_Data + sendcount,count);
count -= sendcount;
} while(count > 0);
}void CFileRDlg::ReceiveData(CMysock *sock)
{
int Recount = 0;
int count = SIZE_CFileData;  // 结构体的大小,即一个包的长度
do
{
Recount = sock->ReceiveMsg(&m_Data + Recount,count);
count -= Recount;
} while(count > 0);
}m_Data 是类成员。一个如下的结构体
struct CFileData
{
int Msg;
int count;
BYTE buf[1000];
};这是我修改以后接收和发送的函数，考虑了一次没发完或没接完的情况。这样如果没发完或
没接收完整都会继续发剩下的或接收剩下的。
不过就像我前面说的：当我传送数据的时候，a[1]到达了  a[2]的前一部分到达了  a[3]到达了， a[2]的后一部分到达了。   这种情况下还是会乱。还有个疑问就是，发多少我接多少。程序为什么会出错呢？顶多是接收完的文件乱了，程序为什么运行部下去？

有没有谁清楚：struct A
{
    int a；
    BYTE buf[1000]；
} A  a[3]; 我按a[1] a[2] a[3] 发送数据,数据可能会a[1] a[3] a[2]到达这我能理解。但是可不可能
a[1] a[2]的一部分 a[3] a[2]的剩下一部分   这种情况呢？如果是这样那就很不好办了啊，数据包乱了不要紧，比方说上面的，我可以用a来判断顺序，但如果
传输的时候一个包被分解了，那就不能根据a来判断了啊！

这个好办,发送方转a[1],接收方一定要收满a[1]才接收a[2],TCP是有序的

谁把我的问题解释下好吗？可不可能 a[1] a[2]的一部分 a[3] a[2]的剩下一部分这种情况呢？
这很重要啊也就是说我发一个包出去，会不会接收的时候一个包变好几个了

TCP不会给你乱序的，也不会给你给你中间发丢的，发文件建议使用TCP，用UDP你还是一样要做应答，因为文件是一个字节也不允许丢和乱的，而TCP都做好了这层，自己也就没必要重复工作了

就是说我发a[1] a[2] a[3] 那么只有可能顺序乱了不可能出现包被分解是吧（a[1] a[2] a[3]肯定是一个整体）是这意思吗？

估计你用的是socket函数写的
socket在传输的时候有的结构体可能接受的不完整,
要自己检查介绍到的字节数和结构体的size比较.
你可以用CSocket类来实现,可能不用关心这些细节.

http://download.csdn.net/source/1777622

我是用CSocket写的啊 CMysock继承的CSocket 自己稍微封装了下而已这两天自己在写，现在可以传了我现在只想知道：
TCP 我发a[1] a[2] a[3] 接收端的情况可能是怎样？（不会乱序？，不会分包？）UDP呢？知道的说下好不？（这问题解决就结贴给分了）

用tcp发送a[1],a[2],a[3]接受端不会乱序
但是,如果你的a[1]大小是1024,接受到的大小就有可能小于1024然后你需要再接受剩下的字节数.

我发a[1]a[2]a[3]
也就是说TCP发过来的肯定是 a[1]a[2]a[3]这样的顺序对吧
不会是a[1]a[3]a[2] 或者a[1] a[2]一部分 a[3] a[2]另一部分这种情况吧。UDP呢？情况会很复杂？

TCP是顺序是不会乱的，不过如果是没封装的Socket程序仍然需要处理分包，IP分片的大小如果大于1500就不能发送了。所以你的数据包应该控制到这个范围内，如果是支持外网特别是UDP发送的情况应该控制到1000左右，这个只是我个人测试时的经验数据。UDP发送时接收端收到的顺序可能会出现错误也就是你说的1 3 2的顺序，需要缓存以及给每个包编号然后还原数据顺序来处理。另外还可能出现丢包现象，如果是传送文件还需要你自己处理重发机制等等

完成端口就是重叠异步IO完成端口的简称,也就是IOCP,他只是一种通信模型,和select WSAAnyncSelect event等等是平级的,你可以先不管这个
发文件你可以选UPD和TCP都可以,UPD要麻烦得多,因为UPD可以丢包的,所以你得做校验,而且你第一次发的,他不一定是第一次收到的,也不一定能收全,但他的速度是最快的.TCP就简单多了,只要建一条连接,然后在服务端顺序读文件,并发给客户端,然后客户端顺序写文件就行了,不用做校验,也不用但心先发的后到,数据没收完等问题,但速度慢一点.如果你在局域网,或者在网络比较好的时候,你感觉不到的.

我是用CSocket类的算是封装了Socket的吧应该不会分包了吧

UDP 会不会出现 a[1] a[2]一部分 a[3] a[2]另一部分这种情况？

面向流的TCP才会出现你说的那种情况，UDP是面向包的。我没遇到过你说的那种情况，要么就是收不到。你用CSocket使用TCP时ms使用的Nagle算法可能会出现你说的那种情况。

说白了就是这个意思，做网络编程最好别用MFC的类，那东东不好用，初学最好用TCP，1次最好发1000字节左右，一般做网络编程得自己定义协议的，每一次发的数据是啥，第几次，校验码是啥是数据还是文件头信息，等等，也描术清楚，明白吗，如果不明白，加我QQ：372898309，来我们一起学习，怎么样

你采用TCP的话，接收端是一般是不会出现乱序现象（除非发送缓冲区满了，发送数据被丢弃），只可能出现a[1]的一部分，a[1]的第二部分，.....a[1]的第n部分,a[1]的第n+1部分和a[2]的一部分,........，因此最好自己定义一个简单的通信协议，就是在每次发送时加入一个自定义的报头，接收时根据报头来接收。

LZ好象是初学者的，TCP和UDP还没有分清楚呢，最好先搞清楚这个再说。打个比方说吧，在应用层看来，TCP就象双方连立了一个通道，一端的东西流向另一端，可以当成是有序无差错的，但也是无界的，没有包的概念，只是字节流，你要自己处理解析。而UDP就象有一个人不停地把东西打成包丢给你，你有可能能接收到，也有可能接收不到，也有可能他先丢的包你后接到，先丢的你先接到。但有一个好处，就是除非你不接到，如果你接到就是一整个包。TCP的优点是稳定性好，缺点是占资源比较多；UDP的优点时速度快，缺点时稳定性差。具体那一个协议好？没有绝对的标准，只有哪一个更适应你的应用场景。象网络的语音和视频等，丢失一点数据不算什么大不了的事，所以一般采用UDP。对于交易数据或其它重要数据，当然就用TCP了。关于传文件这事，就不太好说了，基本上是功底不太好的就用TCP，毕竟比较简单，如果功底很好又愿意花时间的，就采用UDP了，因为如果处理得应的话，性能可以比TCP高一些。而且在某些应用环境里，只有UDP才能行得通。回到你说的问题，你是以包为单位发的，看起来象是用UDP。但很明显，你没有对其做额外处理，这样传文件基本上是不可能成功（除非文件足够小，网络条件足够好）。当然这只是猜测了，说不定你是用TCP。如果是用TCP还有这个问题的话，那就是我前几天说的，发送太快造成发送缓冲区满。

调试易

求：大文件传输程序（比方说传电影）

解决方案 »