incubator-bluesky-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shan Jiang <dane.x...@gmail.com>
Subject Re: Re: Re: About the DTU + P2P tree structures
Date Fri, 17 Dec 2010 09:26:02 GMT
Is the header of rtp used by FEC encoder/decoder ? If done, the header of
rtp can not be remove smoothly.

2010/12/17 du.haipeng <du.haipeng@gmail.com>

>
> a frame of encoded data from avmeeting shoud be sent to this dtu module.
>
> dtu module will send this data to remote according to a list.
>
> dtu module receives data from its parents, deliver it to avmeeting for play
> back, and at the same time,
>
> send to remote as a p2p client.
>
> avmeeting dont need to communicate with others, this will be done by dtu
> module, may be with rtp.
>
> so i think rtp can be removed from avmeeting since it just need to
> communicate with dtu module localy.
>
>
> 2010-12-17
>
>
>
> du.haipeng
>
>
>
> 发件人: hz nan
> 发送时间: 2010-12-17  16:53:04
> 收件人: bluesky-dev
> 抄送:
> 主题: Re: Re: About the DTU + P2P tree structures
>
> hi:
> now the avmeeting has contains the module of rtp, so remove it from them
> may
> be very difficult,why need to remove?
> the dtu need the method of rtp?
> nan hongzhen
> 2010/12/17 du.haipeng <du.haipeng@gmail.com>
>  > hongzhen:
> >
> > how about avmeeting sending data, video,audio and screen, to dtu module
> > instead of sending itself?
> >
> > rtp can be removed from avmeeting and then avmeeting can focus on media
> > data magement.
> >
> >
> > 2010-12-17
> >
> >
> >
> > du.haipeng
> >
> >
> >
> > 发件人: Nanhz
> > 发送时间: 2010-12-15  11:21:45
> > 收件人: bluesky-dev
> > 抄送:
> > 主题: Re: About the DTU + P2P tree structures
> >
> > Do you mean each student client has a dtu module, and the avmeeting
> module
> > only connect with dtu in the same machine ,and dtu only connect with
> other
> > dtu in the background of student or teacher client but not other
> avmeeting
> > module?
> >
> >
> > nan.hongzhen
> >
> > --- 10年12月14日,周二, du.haipeng <du.haipeng@gmail.com> 写道:
> > > 发件人: du.haipeng <du.haipeng@gmail.com>
> > > 主题: Re: About the DTU + P2P tree structures
> > > 收件人: "bluesky-dev" <bluesky-dev@incubator.apache.org>
> > > 日期: 2010年12月14日,周二,下午6:16
> > > i have wrote an independent udp
> > > module that will transmit received data to destinations
> > > according to some lists.
> > >
> > > but it hasn't been tested yet.
> > >
> > > hongzhen is trying to manage it with avmeeting
> > > loosely-coupled.
> > >
> > > the module will have a local destinaion by default for
> > > avmeeting and some remote destinaions.
> > >
> > > the prototype is one dtu + p2p tree structure.
> > >
> > > i think it's better to deal with dtu tree and node failure
> > > treatment the next step.
> > >
> > > 2010-12-14
> > >
> > >
> > >
> > > du.haipeng
> > >
> > >
> > >
> > > 发件人: 张未展
> > > 发送时间: 2010-12-14  17:41:11
> > > 收件人: bluesky-dev
> > > 抄送:
> > > 主题: About the DTU + P2P tree structures
> > >
> > > Hi,
> > >     My consideration about the structure of
> > > Bluesky is the DTU trees with the
> > > P2P meshed overlays. Because of the dynamic nature of
> > > peers, the P2P tree
> > > structure is rarely used in pratice. For this reason, I
> > > think that multiple DTU
> > > trees for multi-channels are more useful than the P2P
> > > trees, which also stands
> > > in line with our future plan. From the aspect of
> > > implmentation, the
> > > construction of DTU trees is quiet similar with P2P trees.
> > > The only difference
> > > is to further identify the channel IDs of the DTUs, which
> > > is known for peers
> > > naturally.
> > >      Another concern is about the
> > > transfer unit fuction for the peers, I think
> > > it should somhow be a independent module, loose-coupled
> > > with Avmeeting using
> > > communication mechnism.
> > > all the bests
> > > Weizhan Zhang
> > >
> > >
> >
> >
>



-- 
Shan Jiang a.k.a dane @ Bluesky Dev Team XJTU

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message