<blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote"><pre>No, because the server's writes to the TCP socket will be non-blocking.<br><br>The underlying OS (in its implementation of TCP) will accept the data <br>
immediately, but, if necessary, buffer the outgoing data until it can <br>be sent.<br></pre></blockquote><div>If the underlying OS socket buffer is unlimited, the reasoning should be all right. However, according to the manpage of <a href="http://www.manpagez.com/man/2/send/">send()</a>:<br>
<blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote"><pre>If no messages space is available at the socket to hold the message to be<br>transmitted, then <b>send</b>() normally <b>blocks</b>, unless the socket has been<br>
placed in non-blocking I/O mode. The <b><a href="http://www.manpagez.com/man/2/select/">select(2)</a></b> call may be used to<br>determine when it is possible to send more data.</pre></blockquote><div>That is, the calling to send() does actually blocks if no underlying message space is available!<br>
</div></div>Besides, after reviewing the wis-streamer, I think the streaming process can apply an either pull or push model on different ServerMediaSubsessions, right?<br><br><div class="gmail_quote">2009/2/17 Fuzzy Lai <span dir="ltr"><<a href="mailto:fuzzylai@dynagrid.net">fuzzylai@dynagrid.net</a>></span><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Dear Sir:<br><br>After reviewing the server side implementation, I think the streaming process is a pull model, isn't it?<br>
<br>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?<br>
<br>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?<br>
<br>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?<br><br>Of course, one should handle the coded frame dropping issue if the prepared tcp sending buffer is full.<br>
<br>Is my reasoning OK?<br><br>BR<br><font color="#888888">Fuzzy Lai<br>
</font></blockquote></div><br>