前面问了几次都没得到答案,希望这次能令我兴奋!
我写了款C/S模式的程序,S充当索引服务器。C即充当文件源服务器又充当客户,一个客户可以同时向几个源请求文件,程序有点象BT这样的P2P软件。
我在内网测试文件传输速度在1M/S左右,在广域网上速度有好有坏,快的话也是1M/S左右,但慢的话收包就时断是续有时甚至一个包也收不到,如果包中的文件块调小的话,相对原先收包率低的主机收包率会有所提高(应该是包越小收包率越高)
我在广域网测试的大部分结果都不好,一般在40K/S,我只希望能达到100K/S以上,尽请前辈们赐教!

解决方案 »

  1.   

    服务器与客户之间是通过UdpClient和TcpChannel实现通信的。
    在客户之间就只使用UdpClient通信(有点想改为Tcp通信,但水平不够)。
      

  2.   

    同样也不熟悉网络编程,无间道wangsaokui最近在搞这个,可以问问他
      

  3.   

    wangsaokui好像一直都在搞这个 :-)// 服务器与客户之间是通过UdpClient和TcpChannel实现通信的
    究竟是udp还是tcp?包太大了或者太小了都会影响性能,设置在4kb左右比较合适嗯
      

  4.   

    应该也给wangsaokui留言了,在"任命Sunmast为本版大版主"上基本上一个个留言过去的。
    如果文件600M的话,一个包要是只有4K那要传多久啊,我目前是用50K或者10K,即使是10K一些客户还是收不到包,如果包再小势必影响到传输时间,所以现在不知道该怎么办,望大虾吗帮助……
      

  5.   

    你先看看这个:
    http://www.linuxforum.net/books/ethernet-howto/Ethernet-HOWTO-4.html
      

  6.   

    http://www.linuxforum.net/books/ethernet-howto/Ethernet-HOWTO-4.html
    看过了,以现在的网卡性能应该不要考虑这些吧?
    在一段时间内请求的包数量基本上是相同的,只是包中文件块大则收包率低、文件块小则收包率就高。
    应该不会是数据包相互覆盖的原因。
      

  7.   

    包太大的话,一旦出错,整个包都要重新发送
    把包设置得很大对性能提升的作用有限,控制位占不了多少字节,而internet上数据传输的可靠性远不如局域网
    所以是不是有点得不偿失了?
      

  8.   

    就是因为“internet上数据传输的可靠性远不如局域网”所以不知道该咋办啊。
    如果包太小,相应的包数量就变大,伴随着文件的传输时间就成倍地增加,所以包大了不好、小了也不好(不希望把包大小改为动态的)。
    不知BT到底是怎么实现的。
      

  9.   

    服务器与客户之间是通过UdpClient和TcpChannel实现通信的
    登陆时用UdpClient
    后面一些客户与服务器的通信(如刷新用户在线时间)用TcpChannel
    上面的服务器是纯服务器(中央索引服务器),不是指客户。
      

  10.   

    1%的包的丢失,可能造成80%的性能下降
    Why?
    我在收包时没判断某个包是否收到,但在发送请求时该请求那些包有判断,比如说还没有被请求下载的包或者曾经被请求过但一段时间后还没收到的包。
      

  11.   

    究竟是tcp还是udp?我是说传输数据的时候
    如果是tcp,根本没必要自己校验数据,tcp协议自己会做这个工作你为什么不先设置为4kb试一下?
      

  12.   

    能加我QQ或者留下你的QQ吗?
    这样交流太慢了!
    我的QQ:12471944
      

  13.   

    但是客户之间没办法用TCP啊
    至少目前我还这个水准啊……
      

  14.   

    sorry,没有看见你的留言,是刚才一瓢MSN找我才看见的
    你可以考虑使用多播,利用UDP协议,可以将多播消息发送到一组由D类子网地址标识的系统,具体的你可以看WROX的.Net 网络高级编程第七章的例子
      

  15.   

    对于成千上万个客户参与的事件来说,服务器和网络上的负荷将会相当大,多播意味着服务器只需将消息发送一次,随后这些消息将被发布到整个客户组,并且只向那些参与网络组的成员系统传输消息,适用于将大数据包发送到多个客户,而无须占用很大百分比的网络带宽的情况,美国曾经在1994年通过internet传输了一场现场音乐会,所以肯定能满足你的需要。
      

  16.   

    to wangsaokui: 好象你理解错了。
    传输文件主要是在客户之间相互进行的,服务器只参与打洞之类的消息转发或应答。
    在传输文件过程中相对一个特定的包而言接收方和源是特定的,没必要用转发吧?
    还请指教。
      

  17.   

    udp的数据宝尽量保证<2k因为udp最大数据包为2k,data+包头信息=2k是最好的,如果大于2k,数据包会被分割陈若干个<=2k 的数据包发送,这样就容易丢包,你又必须重发,速度自然慢些哪
    TcpChannel应该是netRemote中的东西吧,用这个通讯,相对直接用socket通讯速度肯定慢些,不过很方便,东西容易用了,性能自然慢些哪^_^
      

  18.   

    好象目前也就只能把包大小改为动态的了,要是有VPN或VNN就好喽?