> > 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 <fuzzy...@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 >
_______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
