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
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
>
> 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
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?
No, because the server's writes to the TCP socket will be non-blocking.
The un
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
