Re: TCP communication for raw image transmission

[Rick Jones <rick.jones2@hp.com>]

On 01/05/2012 10:53 AM, Eric Dumazet wrote:
> Le jeudi 05 janvier 2012 à 10:41 -0800, Rick Jones a écrit :
>
>> Why?  A netperf UDP_STREAM test is "purely" unidirectional (*).  I
>> suspect the numbers look funny thanks to the 32-bit compilation bugs
>> (format statement issues).
>
> Unidirectional, but the receiver must send some status notifications ?
>
> My reasonning (before you explained the compat problem between sender
> and receiver) was that since we flooded the link, we were blocking
> output from receiver (because of collisions), and

Well, the flow goes something like

*) netperf establishes control connection
*) netserver accepts and forks
*) netperf sends initial test request and configuration
*) netserver sends final test setup information
*) netserver starts timer (with padding)
*) netperf starts timer
*) netperf's timer expires, netperf stops sending, starts waiting for 
results from netserver (in a select with a one or two minute timeout)
*) netserver's timer expires, sends its part of the test results
*) netperf comes out of select and receives netservers information
*) netperf displays results

If the netserver's results were blocked by some massive backlog of data 
in queues somewhere, the results will either simply be delayed, or 
netperf's select() will timeout and errors will be reported.  It would 
not result in netperf reporting results without netserver's input.

happy benchmarking,

rick jones