yhec(@_@)为什么要等呢你一直发好了,发和接受可以同步运行的啊。

解决方案 »

  1.   

    具体要编个传屏幕图像的程序试试,不断总结,
    对方屏幕图象生成jpg格式,再分成若干个小包,发送出去,
    再拼成一起还原出图像:
    两种方法都试试:
       1.发一个包,等待对方确认后,再发下一个,此法好编,但效率太低;   2.包全发出去,同时核对后,通知再发丢掉的包,效率很高,但编程可能
         有点麻烦,收到的包都要先存起来,完整后,最后才能释放空间;
    比较这两种的传送时间.
      

  2.   

    >>包全发出去大哥,不要全发啊,8个一发比较好,大小可以设定在1.5K左右
      

  3.   

    说来容易做来难呀“对每个包进行顺序编号,再加校检字节,接收端一旦发觉编号顺序不对或校验字节不对,通知重发.“理论上早解决了,但实践并没有实现。TCP/IP已经发展了这么多年儿没解决这个问题估计还有很多未知的因素在起作用呀
      

  4.   

    采用第一种方式,我觉得还不如使用tcp/ip来传送.
    采用第二种方式,还得自己做分拆和合并的工作,不过至少会比较好一点.至少可以采用乱序发送.好像也只有这种方法了~~~~~~~~
      

  5.   

    其实udp协议的着重点是速度,例如上面所说的传声音,讲究的是速度,有一点失真没关系.
    大家以为如何?
      

  6.   

    象OICQ,也经常出现丢包现象,但这并不影响它的使用.
      

  7.   

    拜托,发图片自然是用tcp协议啦
    比如oicq的发送文件
    就需要连接~~~用udp实在不安全~~
      

  8.   

    tcp只能用于单播,而udp可以用于多播和广播.
      

  9.   

    tcp是面向连接的服务,意味着两个使用tcp的应用在交换数据前必须先建立一个tcp连接.
    广播怎样建立tcp连接?
      

  10.   

    先不说广播吧,会走题的;
    UDP丢包的原因是什么?如果发的包太多太快,会不会引起包丢得更厉害!如果发送小包,发送一个,确认一个,处理一个,没什么问题;如果是发送文件,若每发送一个小包,都确认一个的话肯定太慢,
    所以,OICQ的客户间发送文件就采用TCP协议,若客户双方都是局域网,
    它就拒绝发送了,说双方都有防火墙;
       OICQ设计得非常巧妙、合理,客户跟服务器用UDP,极大地减轻了服务器
    的负担,费时的操作让你客户与客户自行处理;
      

  11.   

    tcp协议的最大毛病是要连接,而一个系统的socket连接数一定有限(极限值不知为多少?),
    就拿OICQ来说,几十万的QQ们都连接过去将会怎样,可以想象;
      

  12.   

    UDP要编个程序试试,才能有数
      

  13.   

    上面是C++BUILDER网友们的看法,
    delphi人气这么旺,朋友们为何一言不发?!
      

  14.   

    delphi的思路和c查不多
    网络书中有滑动窗口协议用于实现TCP的可靠连接,不妨借来用
      

  15.   

    老大,可以说不丢包的UDP就是TCP/IP协议