同时对文件读写的效率问题

ww95211

我先将遇到的问题描述一下:
客户端A将一个文件通过服务器转发给另外的客户端B和C,其中B和C会同时收到需要去接收这个文件的请求,B和C不可能同时都会去响应接收请求,当B或C只要有一个人响应接收请求后,A会开始发送文件,由于这个时候B和C可能不是同时接受文件,此时服务器需要将此文件做缓存,以便C或B迟一步响应接收请求可以完整的接收此文件.因此服务器需要一边将此文件进行写,一边读出来发给B和C.但是这样的效率比较低,速度比较慢.如果是同时给五六个传会更慢.请问有没有更好的办法处理服务器上对文件的同时读写操作,以便提高效率?

依赛特小子

生产者和消费者算法！效率比较好吧！

cellar

是不是应该考虑对每一个客户端用都一个子进程（线程）来发送？或者多播？这个不熟，仅供参考，等待高手的高招

renstone921

去研究一下bt的协议。

nhw_cs

既然是通过服务器转发,那合理的做法是:服务器从A将文件信息全部接收到(放在内存当中)后才能将其发给B,C,也就无所谓同时读写了.如果要达到你所描述的"同时读写",不仅实现复杂,而且不可靠(如从A接收的过程中出错怎么办).

kukoo

操作系统一般都会处理这种情况，比如linux，最近读过的文件都在缓存里面了，根据2－8原则，大部分都可以命中。除非实际性能测试证明有必要，否则先不要动为好。

你传送的文件多大？

kukoo

操作系统一般都会处理这种情况，比如linux，最近读过的文件都在缓存里面了，根据2－8原则，大部分都可以命中。除非实际性能测试证明有必要，否则先不要动为好。

你传送的文件多大？

jamesfork

不赞成使用这种方式，同意nhw_cs 的说法

ww95211

谢谢各位的回复.
回复nhw_cs :
服务器每次接收一个从客户端发来的数据包后,会放在一个buffer里,然后有另一个线程从buffer里读出,然后发送出去,如果写入的速度比读出的速度快(也就是客户端发送速度比服务器发送的速度快),buffer到一定的程度会满,这个时候服务器会写不进buffer,会通知客户端再发送一次刚才失败的数据.至于你说从A中接收不到数据包,我想这在TCP协议里有保证,会告诉A发送失败的,需要再次发送的.你说的从A全部接收完了(放在内存中)以后再转发给B和C,这种情况我们也考虑过,假如B或C一直没有接收,只有其中一个人接收的时候,这块内存是不能被释放的,因为这些数据还要传给另一个人.一个文件是可以的,如果同时有十来个文件,大写有一两百M的话,请问这个时候服务器还有多少内存剩下可用呢?
回复kukoo:
我们做测试的文件有大小有小,小的就是几十个字节,大的有一两百兆,你说的没错,操作系统是一般会处理这种情况的,但是频繁的读写服务器也不知道如何处理.现在出现的情况就是这样的.你说的2-8原则能不讲出来与大家分享一下,让大家一起提高一下?
回复bennie :
我们是主要传输多媒体文件的,是流文件.