[Live-devel] Handle frame dropping elegantly on clients with limited output bandwidth

[Fuzzy Lai]

>
> No, because the server's writes to the TCP socket will be non-blocking.
>
> The underlying OS (in its implementation of TCP) will accept the data
> immediately, but, if necessary, buffer the outgoing data until it can
> be sent.
>
> If the underlying OS socket buffer is unlimited, the reasoning should be
all right. However, according to the manpage of
send()<http://www.manpagez.com/man/2/send/>
:

> If no messages space is available at the socket to hold the message to be
> transmitted, then *send*() normally *blocks*, unless the socket has been
> placed in non-blocking I/O mode.  The *select(2) <http://www.manpagez.com/man/2/select/>* call may be used to
> determine when it is possible to send more data.
>
> That is, the calling to send() does actually blocks if no underlying
message space is available!

Besides, after reviewing the wis-streamer, I think the streaming process can
apply an either pull or push model on different ServerMediaSubsessions,
right?

2009/2/17 Fuzzy Lai <fuzzylai at dynagrid.net>

> Dear Sir:
>
> After reviewing the server side implementation, I think the streaming
> process is a pull model, isn't it?
>
> Besides, when the frame data is pulled readily, the event loop will
> scheduled to send the frame immediately no matter the output channel is over
> UDP or TCP, won't it?
>
> The problem is that if two clients, one of which is over UDP while the
> other is over TCP and has only limited bandwidth, the transmitting rate of
> the UDP client seems to be influenced by the slow TCP client, right?
>
> If such a problem does exist, how about separating the tcp sending process
> from the frame pulling one and doing the sending in the event loop only when
> the output tcp socket is writable?
>
> Of course, one should handle the coded frame dropping issue if the prepared
> tcp sending buffer is full.
>
> Is my reasoning OK?
>
> BR
> Fuzzy Lai
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20090218/035bceab/attachment-0001.html>