Re: [Farsight-devel] Farsight RTP documentation

2011-03-07 Thread Tiago Katcipis 
Dont know if i missed some detail, but it seems to be done :-).

http://www.inf.ufsc.br/~katcipis/farstream/farstream.png
http://www.inf.ufsc.br/~katcipis/farstream/farstream-rtpsession.png
http://www.inf.ufsc.br/~katcipis/farstream/farstream-rtpsubstream.png

Original dia files:
http://www.inf.ufsc.br/~katcipis/farstream/

If the imagens are good enough to be added to farsight documentation i
relinquish any right to the images, it would be a pleasure to help farsight
documentation.
--
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d___
Farsight-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/farsight-devel

Re: [Farsight-devel] Farsight RTP documentation

2011-03-07 Thread Tiago Katcipis 
2011/3/7 Olivier Crête 

> On Mon, 2011-03-07 at 11:43 -0300, Tiago Katcipis wrote:
>
> > Decodebin is not
> >
> >
> > really suitable, because for RTP, you need to discover all the
> > possible
> > codecs before starting the call (so before getting any data),
> > so that
> > the codecs can be negotiated with the other side. While
> > decodebin just
> > decodes as it goes along.
> >
> > Dont know if i get the problem correctly, but if you need to now the
> > available codecs on the client you could do something similar to what
> > decodebin already does with gst_element_factory_list_get_elements,
> > listing only GST_ELEMENT_FACTORY_TYPE_DECODABLE, do negotiation, and
> > then let decodebin do his job when data arrives. Well it is just an
> > idea...again...i dont know if would cover all the cases that farsight
> > needs to handle ( and it handles just fine :-) ).
>
> To know if a codec can be used, I need to check if there is a payloader,
> a depayloader, an encoder and a decoder. And once I found all of those,
> I don't really need decodebin anymore (since I know all the elements I
> need).
>

yeah, now the blueprint stuff make a lot of more sense :-).

Thanks Olivier.


>
> --
> Olivier Crête
> [email protected]
> Collabora Ltd
>
>
> --
> What You Don't Know About Data Connectivity CAN Hurt You
> This paper provides an overview of data connectivity, details
> its effect on application quality, and explores various alternative
> solutions. http://p.sf.net/sfu/progress-d2d
> ___
> Farsight-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/farsight-devel
>
>
--
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d___
Farsight-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/farsight-devel

Re: [Farsight-devel] Farsight RTP documentation

2011-03-07 Thread Olivier Crête 
On Mon, 2011-03-07 at 11:43 -0300, Tiago Katcipis wrote:

> Decodebin is not
> 
> 
> really suitable, because for RTP, you need to discover all the
> possible
> codecs before starting the call (so before getting any data),
> so that
> the codecs can be negotiated with the other side. While
> decodebin just
> decodes as it goes along.
> 
> Dont know if i get the problem correctly, but if you need to now the
> available codecs on the client you could do something similar to what
> decodebin already does with gst_element_factory_list_get_elements,
> listing only GST_ELEMENT_FACTORY_TYPE_DECODABLE, do negotiation, and
> then let decodebin do his job when data arrives. Well it is just an
> idea...again...i dont know if would cover all the cases that farsight
> needs to handle ( and it handles just fine :-) ).

To know if a codec can be used, I need to check if there is a payloader,
a depayloader, an encoder and a decoder. And once I found all of those,
I don't really need decodebin anymore (since I know all the elements I
need).

-- 
Olivier Crête
[email protected]
Collabora Ltd


signature.asc
Description: This is a digitally signed message part
--
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d___
Farsight-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/farsight-devel

Re: [Farsight-devel] Farsight RTP documentation

2011-03-07 Thread Tiago Katcipis 
2011/3/4 Olivier Crête 

> On Fri, 2011-03-04 at 15:43 -0300, Tiago Katcipis wrote:
> > And what is the purpose of FsRtpStream since all the job is done on
> > FsRtpSubStream ?
>
> A FsRtpStream is there because this is what is used for candidates and
> transmitters and stuff. And it is what is in the API, a Stream is a
> Participant in a Session.
>
>
>
> > I finished the FsRtpSubStream diagram and updated the FsRtpConference
> > one:
> >
> > http://www.inf.ufsc.br/~katcipis/farstream/farstream.png
> > http://www.inf.ufsc.br/~katcipis/farstream/farstream-rtpsubstream.png
>
> Looks good
>
> >
> >
> > The rest of your diagram seems fine. You're missing the
> > discovery thing
> > too (on the send side).
> >
> > I was planning on documenting this on the send pipeline (FsRtpSession
> > diagram):
> >
> > http://www.inf.ufsc.br/~katcipis/farstream/farstream-rtpsession.png
> >
> > Can you explain better how the "discovery thing" works? (I'm taking a
> > look at the fs-rtp-session code, but somethings are hard to get).
>
> The discovery thing is pretty simple. For some codecs (like THEORA), to
> produce all the parameters that you want to send the other side, you
> need to process some data, to get at least the caps from the incoming
> side. So what the discovery stuff does is that, for these codecs, it
> creates a small pipeline like "codecbin->fakesink" and waits for the
> caps to bet set after the codecbin and uses those to complete the
> codecs. When they have all been discovered, the "codecs-ready" property
> becomes true.
>

Thanks Olivier, that will help me a lot on the diagrams.


>
>
> > I guess these files should have a bit more documentation on
> > what they're
> > supposed to do.
> >
> > The codecbin, blueprint, etc part is pretty hard to understand (if
> > someone wants to understand the final pipeline that will be built), is
> > there a reason why decodebin and encodebin are not used to build the
> > send/receive pipelines? it seems you use an autoconvert element and a
> > list of factories, never read about autoconvert before.
>
> First, encodebin did not exist when this was written.


My mistake, encodebin is pretty new stuff on gstreamer.


> Decodebin is not
> really suitable, because for RTP, you need to discover all the possible
> codecs before starting the call (so before getting any data), so that
> the codecs can be negotiated with the other side. While decodebin just
> decodes as it goes along.
>

Dont know if i get the problem correctly, but if you need to now the
available codecs on the client you could do something similar to what
decodebin already does with gst_element_factory_list_get_elements, listing
only GST_ELEMENT_FACTORY_TYPE_DECODABLE, do negotiation, and then let
decodebin do his job when data arrives. Well it is just an idea...again...i
dont know if would cover all the cases that farsight needs to handle ( and
it handles just fine :-) ).


>
> A Blueprint is just a simple structure that defines a codec (as RTP sees
> it), so it includes the codec's info (a FsCodec), the rtp and media caps
> (that is the caps after and before the payloader), and the list of
> factories to make an encoding or decoding blueprint for this codec. So
> in almost all cases, these lists will only contain a encoder/payloader
> pair and a decoder/depayloader pair. That said, there is one strange
> case, H263-1998/H263-2000, where (in ffmpeg) there are two different
> encoders (ffenc_h263 and ffenc_h263p) to be used depending on the exact
> parameters. The way we solved this is by putting both of these in
> autoconvert and letting it decide according to the caps.
>
> The code is fs-rtp-discover-codecs is kind of gash, but it works (and
> hasn't changed in many years).
>
> I hope that helps.
>

Helped me a lot Olivier, thanks.

Now i think i can finish my diagrams :-). I'll post them here when I'm done.


>
> --
> Olivier Crête
> [email protected]
>
>
> --
> What You Don't Know About Data Connectivity CAN Hurt You
> This paper provides an overview of data connectivity, details
> its effect on application quality, and explores various alternative
> solutions. http://p.sf.net/sfu/progress-d2d
> ___
> Farsight-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/farsight-devel
>
>
--
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d___
Farsight-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/farsight-devel

Re: [Farsight-devel] Farsight RTP documentation

2011-03-07 Thread Tiago Katcipis 
On Fri, Mar 4, 2011 at 6:11 PM, Youness Alaoui <
[email protected]> wrote:

> On 03/04/2011 01:43 PM, Tiago Katcipis wrote:
> > Thanks for the help Olivier.
> >
> > 2011/3/4 Olivier Crête  > >
> >
> > On Fri, 2011-03-04 at 10:09 -0300, Tiago Katcipis wrote:
> >  > - Hints on how to document the rest of the Rtp conference in
> detail
> >  > (the most important source code to give me understanding on how it
> >  > actually works).
> >  > - What exactly is a FsRtpSubStream? only looking at the source
> code
> >  > didn't helped me too much, it seems that all the work is done on
> the
> >  > rtp substream, what is the rtp stream for ?
> >
> > The red boxes on your diagram labelled "FsRtpStream" are actually
> > substreams. A sub stream is one codec received from one ssrc in one
> > session, it should contains
> valve->capsfilter->codecbin->valve->ghostpad
> > as documented at the top of the file. The substream object contains
> > everything for the receive side (the send side is in the session
> > object).
> >
> >
> > And what is the purpose of FsRtpStream since all the job is done on
> FsRtpSubStream ?
>
> FsRtpStream is basically the stream, a new FsRtpSubStream will be created
> by the
> stream everytime a new ssrc/codec is received.
> Assuming you are doing an audio call with someone and you use PCMA, then
> you
> have one FsRtpStream initially that you created for the peer, when you
> receive
> the PCMA audio data, you'll get a new FsRtpSubStream created to handle this
> codec for this peer (ssrc). If the peer sends you DTMF for example, then a
> new
> FsRtpSubStream will be created to handle the 'telephone-event' codec.
> Externally, the user only needs to know about the stream (a
> session-participant)
>

Thanks Youness, now its a lot clearer.


>
> >
> >
> > The first valve is used if you want to stop receiving, the output
> valve
> > is opened once it knows which FsStream the substream belongs to.
> >
> > A codec bin is a "encoder->paylaoder->capsfilter" or
> > "capsfitlers->depayloader->decoder" depending on the direction.
> >
> >
> > I finished the FsRtpSubStream diagram and updated the FsRtpConference
> one:
> >
> > http://www.inf.ufsc.br/~katcipis/farstream/farstream.png
> > http://www.inf.ufsc.br/~katcipis/farstream/farstream-rtpsubstream.png
> >
> >
> > The rest of your diagram seems fine. You're missing the discovery
> thing
> > too (on the send side).
> >
> >
> > I was planning on documenting this on the send pipeline (FsRtpSession
> diagram):
> >
> > http://www.inf.ufsc.br/~katcipis/farstream/farstream-rtpsession.png
> >
> > Can you explain better how the "discovery thing" works? (I'm taking a
> look at
> > the fs-rtp-session code, but somethings are hard to get).
> >
> >
> > I guess these files should have a bit more documentation on what
> they're
> > supposed to do.
> >
> >
> > The codecbin, blueprint, etc part is pretty hard to understand (if
> someone wants
> > to understand the final pipeline that will be built), is there a reason
> why
> > decodebin and encodebin are not used to build the send/receive pipelines?
> it
> > seems you use an autoconvert element and a list of factories, never read
> about
> > autoconvert before.
>
> yeah, all that blueprint stuff is hard to understand... I'll let Olivier
> explain it.
> autoconvert is an element that was created for/was part of farsight (called
> fsselector iirc). All it does is to basically try to find the right
> 'converter'
> from one format to another...
> if you do "audio/mp3 ! autoconvert ! audio/raw-int" it will find the right
> decoder... I believe it it used by farsight in order to automatically find
> the
> depayload and the decoder, as well as the encoder/payloader for the
> send/recv
> codec bins.
>

On a recently project that i worked we used "gsrrtpdemux -> decodebin2" to
decode any type of rtp, the demuxer will detect the type of the rtp packet,
decodebin2 with the rtp packet defined properly can find the depayloader and
the decoder to the media inside the rtp packet. It worked fine for us but i
dont know if it would be a good solution for Farsight (maybe some fallback
that i cant see right now).

The automaticaly encode part is trickier.


> >
> >
> > --
> > Olivier Crête
> > [email protected]  >
> > Collabora Ltd
> >
> >
> --
> > What You Don't Know About Data Connectivity CAN Hurt You
> > This paper provides an overview of data connectivity, details
> > its effect on application quality, and explores various alternative
> > solutions. http://p.sf.net/sfu/progress-d2d
> > ___
> > Farsight-devel mailing list
> > [email protected]
> >

Re: [Farsight-devel] Farsight RTP documentation

2011-03-04 Thread Olivier Crête 
On Fri, 2011-03-04 at 15:43 -0300, Tiago Katcipis wrote:
> And what is the purpose of FsRtpStream since all the job is done on
> FsRtpSubStream ?

A FsRtpStream is there because this is what is used for candidates and
transmitters and stuff. And it is what is in the API, a Stream is a
Participant in a Session.



> I finished the FsRtpSubStream diagram and updated the FsRtpConference
> one:
> 
> http://www.inf.ufsc.br/~katcipis/farstream/farstream.png
> http://www.inf.ufsc.br/~katcipis/farstream/farstream-rtpsubstream.png

Looks good
 
> 
> 
> The rest of your diagram seems fine. You're missing the
> discovery thing
> too (on the send side).
> 
> I was planning on documenting this on the send pipeline (FsRtpSession
> diagram):
> 
> http://www.inf.ufsc.br/~katcipis/farstream/farstream-rtpsession.png
> 
> Can you explain better how the "discovery thing" works? (I'm taking a
> look at the fs-rtp-session code, but somethings are hard to get).

The discovery thing is pretty simple. For some codecs (like THEORA), to
produce all the parameters that you want to send the other side, you
need to process some data, to get at least the caps from the incoming
side. So what the discovery stuff does is that, for these codecs, it
creates a small pipeline like "codecbin->fakesink" and waits for the
caps to bet set after the codecbin and uses those to complete the
codecs. When they have all been discovered, the "codecs-ready" property
becomes true.


> I guess these files should have a bit more documentation on
> what they're
> supposed to do.
> 
> The codecbin, blueprint, etc part is pretty hard to understand (if
> someone wants to understand the final pipeline that will be built), is
> there a reason why decodebin and encodebin are not used to build the
> send/receive pipelines? it seems you use an autoconvert element and a
> list of factories, never read about autoconvert before.

First, encodebin did not exist when this was written. Decodebin is not
really suitable, because for RTP, you need to discover all the possible
codecs before starting the call (so before getting any data), so that
the codecs can be negotiated with the other side. While decodebin just
decodes as it goes along.

A Blueprint is just a simple structure that defines a codec (as RTP sees
it), so it includes the codec's info (a FsCodec), the rtp and media caps
(that is the caps after and before the payloader), and the list of
factories to make an encoding or decoding blueprint for this codec. So
in almost all cases, these lists will only contain a encoder/payloader
pair and a decoder/depayloader pair. That said, there is one strange
case, H263-1998/H263-2000, where (in ffmpeg) there are two different
encoders (ffenc_h263 and ffenc_h263p) to be used depending on the exact
parameters. The way we solved this is by putting both of these in
autoconvert and letting it decide according to the caps.

The code is fs-rtp-discover-codecs is kind of gash, but it works (and
hasn't changed in many years).

I hope that helps.

-- 
Olivier Crête
[email protected]


signature.asc
Description: This is a digitally signed message part
--
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d___
Farsight-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/farsight-devel

Re: [Farsight-devel] Farsight RTP documentation

2011-03-04 Thread Youness Alaoui 
On 03/04/2011 01:43 PM, Tiago Katcipis wrote:
> Thanks for the help Olivier.
>
> 2011/3/4 Olivier Crête  >
>
> On Fri, 2011-03-04 at 10:09 -0300, Tiago Katcipis wrote:
>  > - Hints on how to document the rest of the Rtp conference in detail
>  > (the most important source code to give me understanding on how it
>  > actually works).
>  > - What exactly is a FsRtpSubStream? only looking at the source code
>  > didn't helped me too much, it seems that all the work is done on the
>  > rtp substream, what is the rtp stream for ?
>
> The red boxes on your diagram labelled "FsRtpStream" are actually
> substreams. A sub stream is one codec received from one ssrc in one
> session, it should contains valve->capsfilter->codecbin->valve->ghostpad
> as documented at the top of the file. The substream object contains
> everything for the receive side (the send side is in the session
> object).
>
>
> And what is the purpose of FsRtpStream since all the job is done on 
> FsRtpSubStream ?

FsRtpStream is basically the stream, a new FsRtpSubStream will be created by 
the 
stream everytime a new ssrc/codec is received.
Assuming you are doing an audio call with someone and you use PCMA, then you 
have one FsRtpStream initially that you created for the peer, when you receive 
the PCMA audio data, you'll get a new FsRtpSubStream created to handle this 
codec for this peer (ssrc). If the peer sends you DTMF for example, then a new 
FsRtpSubStream will be created to handle the 'telephone-event' codec.
Externally, the user only needs to know about the stream (a session-participant)

>
>
> The first valve is used if you want to stop receiving, the output valve
> is opened once it knows which FsStream the substream belongs to.
>
> A codec bin is a "encoder->paylaoder->capsfilter" or
> "capsfitlers->depayloader->decoder" depending on the direction.
>
>
> I finished the FsRtpSubStream diagram and updated the FsRtpConference one:
>
> http://www.inf.ufsc.br/~katcipis/farstream/farstream.png
> http://www.inf.ufsc.br/~katcipis/farstream/farstream-rtpsubstream.png
>
>
> The rest of your diagram seems fine. You're missing the discovery thing
> too (on the send side).
>
>
> I was planning on documenting this on the send pipeline (FsRtpSession 
> diagram):
>
> http://www.inf.ufsc.br/~katcipis/farstream/farstream-rtpsession.png
>
> Can you explain better how the "discovery thing" works? (I'm taking a look at
> the fs-rtp-session code, but somethings are hard to get).
>
>
> I guess these files should have a bit more documentation on what they're
> supposed to do.
>
>
> The codecbin, blueprint, etc part is pretty hard to understand (if someone 
> wants
> to understand the final pipeline that will be built), is there a reason why
> decodebin and encodebin are not used to build the send/receive pipelines? it
> seems you use an autoconvert element and a list of factories, never read about
> autoconvert before.

yeah, all that blueprint stuff is hard to understand... I'll let Olivier 
explain it.
autoconvert is an element that was created for/was part of farsight (called 
fsselector iirc). All it does is to basically try to find the right 'converter' 
from one format to another...
if you do "audio/mp3 ! autoconvert ! audio/raw-int" it will find the right 
decoder... I believe it it used by farsight in order to automatically find the 
depayload and the decoder, as well as the encoder/payloader for the send/recv 
codec bins.

>
>
> --
> Olivier Crête
> [email protected] 
> Collabora Ltd
>
> 
> --
> What You Don't Know About Data Connectivity CAN Hurt You
> This paper provides an overview of data connectivity, details
> its effect on application quality, and explores various alternative
> solutions. http://p.sf.net/sfu/progress-d2d
> ___
> Farsight-devel mailing list
> [email protected]
> 
> https://lists.sourceforge.net/lists/listinfo/farsight-devel
>
>
>
> --
> What You Don't Know About Data Connectivity CAN Hurt You
> This paper provides an overview of data connectivity, details
> its effect on application quality, and explores various alternative
> solutions. http://p.sf.net/sfu/progress-d2d
>
>
>
> ___
> Farsight-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/farsight-devel


--
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, deta

Re: [Farsight-devel] Farsight RTP documentation

2011-03-04 Thread Tiago Katcipis 
Thanks for the help Olivier.

2011/3/4 Olivier Crête 

> On Fri, 2011-03-04 at 10:09 -0300, Tiago Katcipis wrote:
> > - Hints on how to document the rest of the Rtp conference in detail
> > (the most important source code to give me understanding on how it
> > actually works).
> > - What exactly is a FsRtpSubStream? only looking at the source code
> > didn't helped me too much, it seems that all the work is done on the
> > rtp substream, what is the rtp stream for ?
>
> The red boxes on your diagram labelled "FsRtpStream" are actually
> substreams. A sub stream is one codec received from one ssrc in one
> session, it should contains valve->capsfilter->codecbin->valve->ghostpad
> as documented at the top of the file. The substream object contains
> everything for the receive side (the send side is in the session
> object).
>

And what is the purpose of FsRtpStream since all the job is done on
FsRtpSubStream ?


>
> The first valve is used if you want to stop receiving, the output valve
> is opened once it knows which FsStream the substream belongs to.
>
> A codec bin is a "encoder->paylaoder->capsfilter" or
> "capsfitlers->depayloader->decoder" depending on the direction.
>

I finished the FsRtpSubStream diagram and updated the FsRtpConference one:

http://www.inf.ufsc.br/~katcipis/farstream/farstream.png
http://www.inf.ufsc.br/~katcipis/farstream/farstream-rtpsubstream.png


>
> The rest of your diagram seems fine. You're missing the discovery thing
> too (on the send side).
>

I was planning on documenting this on the send pipeline (FsRtpSession
diagram):

http://www.inf.ufsc.br/~katcipis/farstream/farstream-rtpsession.png

Can you explain better how the "discovery thing" works? (I'm taking a look
at the fs-rtp-session code, but somethings are hard to get).


>
> I guess these files should have a bit more documentation on what they're
> supposed to do.
>

The codecbin, blueprint, etc part is pretty hard to understand (if someone
wants to understand the final pipeline that will be built), is there a
reason why decodebin and encodebin are not used to build the send/receive
pipelines? it seems you use an autoconvert element and a list of factories,
never read about autoconvert before.


>
> --
> Olivier Crête
> [email protected]
> Collabora Ltd
>
>
> --
> What You Don't Know About Data Connectivity CAN Hurt You
> This paper provides an overview of data connectivity, details
> its effect on application quality, and explores various alternative
> solutions. http://p.sf.net/sfu/progress-d2d
> ___
> Farsight-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/farsight-devel
>
>
--
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d___
Farsight-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/farsight-devel

Re: [Farsight-devel] Farsight RTP documentation

2011-03-04 Thread Olivier Crête 
On Fri, 2011-03-04 at 10:09 -0300, Tiago Katcipis wrote:
> - Hints on how to document the rest of the Rtp conference in detail
> (the most important source code to give me understanding on how it
> actually works).
> - What exactly is a FsRtpSubStream? only looking at the source code
> didn't helped me too much, it seems that all the work is done on the
> rtp substream, what is the rtp stream for ?

The red boxes on your diagram labelled "FsRtpStream" are actually
substreams. A sub stream is one codec received from one ssrc in one
session, it should contains valve->capsfilter->codecbin->valve->ghostpad
as documented at the top of the file. The substream object contains
everything for the receive side (the send side is in the session
object).

The first valve is used if you want to stop receiving, the output valve
is opened once it knows which FsStream the substream belongs to.

A codec bin is a "encoder->paylaoder->capsfilter" or
"capsfitlers->depayloader->decoder" depending on the direction.

The rest of your diagram seems fine. You're missing the discovery thing
too (on the send side).

I guess these files should have a bit more documentation on what they're
supposed to do.

-- 
Olivier Crête
[email protected]
Collabora Ltd


signature.asc
Description: This is a digitally signed message part
--
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d___
Farsight-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/farsight-devel