请教一下建一个udp服务器的问题。

haohao_h

我想做一个用udp协议的视频服务器，目标是30帧/s，每个udp包最大1400字节。我的问题是怎样把每一帧都完整地传给客户端？初步想法是建两个队列，一个待发送队列，一个已发送队列，（也许还应该有个错误队列，）待发队列中的每一个包发出后就把它挂到已发送队列，客户端对每一个接收到的包都反馈一个确认信息，服务器收到已发送包的确认信息后就从已发送队列中把那个包取消，已发送队列中的包如果在给定时间内（这个时间多长是合适的？）没有收到某个包的客户端确认消息，就重发这个包（要是多次发送仍旧收不到确认信息怎么办？），主要的问题就是上面的超时重发时间多久才是合适的，还有就是我是把数据持续不断的发过去（不管某一帧的数据是否全部接收成功）好呢，还是确保某帧数据全部正确接受之后才发下一帧好呢？成熟的udp服务器使用什么样的策略?

flw

看 TCP 协议。

JohnBull

如果只有一个客户机，为什么不用TCP?

如果多于一个客户机，要么采用REJ重传方案，要么采用流协议而根本不要理会丢报。

haohao_h

总不能把自己的服务器设计成只能接受一个客户端的吧！流协议其实传输协议也是udp协议（所以其实流协议也是会丢包的），不过是在应用层加了处理。我除了要传多媒体流还有其它的一些数据要传，现有的流协议主要是针对流传输的一些优化策略，我不是完全适用。

flw

原帖由 haohao_h 于 2006-11-9 10:51 发表
总不能把自己的服务器设计成只能接受一个客户端的吧！流协议其实传输协议也是udp协议（所以其实流协议也是会丢包的），不过是在应用层加了处理。我除了要传多媒体流还有其它的一些数据要传，现有的流协议主要是针 ...

再仔细看看 JohnBull 的回复！

JohnBull

原帖由 haohao_h 于 2006-11-9 10:51 发表
总不能把自己的服务器设计成只能接受一个客户端的吧！流协议其实传输协议也是udp协议（所以其实流协议也是会丢包的），不过是在应用层加了处理。我除了要传多媒体流还有其它的一些数据要传，现有的流协议主要是针 ...

我说的“一个客户机”还是“多个客户机”指的是你的一个节目流服务多少个客户机，是点播服务还是多播服务。点播的话当然用TCP啦，别自找麻烦。

我说的流协议指的是流媒体编码方式，不必担心丢报的那种，参考公共汽车上的液晶电视，他肯定没有重传机制，只要按固定速率播送即可。

haohao_h

原帖由 flw 于 2006-11-9 10:59 发表

再仔细看看 JohnBull 的回复！

我对JohnBull 的回复有什么理解错误的地方吗？还是直接指出来好了，我比较笨。

wiLinux

suggest using RTSP (Real Time Streaming Protocol), PNM (Progressive Networks Audio) or MMS(Microsoft Media Server protocol).

Because implementing a server is not equal to rewriting part of protocol stack.

This is just my personal viewpoint.

benlan

最合适流媒体数据传输的rtp,看下rtp协议，找个rtp协议库看看，记得ibm有个rtp库还可以，虽有人说效率不很高。

udp无差错控制
tcp传流媒体会滞后，而且带宽需求太大
rtp在udp基础上做了简单的差错等控制，适合流媒体数据的传输

楼上的 rtsp是流媒体数据传输控制协议，如播放，暂停，快进等命令的数据传输，数据量很少，而且不能出差错，用的是tcp

neka

曾做过一个udp的文件传输服务器,采用策略是所有的包都放入超时队列,收到确认包就从超时队列中删除,开启定时器,按照某种策略(时间)重发数据包,重发一定的次数没有确认包就认为超时.