A Berkeley-style send (s, p, N, ..) always returns immediately for large N (over 1 MB), even when the buffer size set by SO_SNDBUF is much smaller than N. This problem also happens when SO_SNDBUF is not set (non-zero default assumed). If SO_SNDBUF is set to 0 (zero), then the call blocks correctly. The call should always block whenever available buffer space is smaller than N.

Back to the top

This feature improves the performance of most existing applications that do only one synchronous send at a time. Some applications may not benefit from this feature, and a possible workaround is available below.

Back to the top

The following wrapper workaround preserves system performance objectives and blocks for a reasonable duration. The workaround maintains a count of bytes already buffered and subtracts them from the current SO_SNDBUF setting.

sendBlock( SOCKET s, PTR p, int cb, int f )
{
    int nSockBuf = GetSockOpt( s, SO_SNDBUF );
    if( cb <= nSockBuf )
        return send( s, p, cb, f );

    cb -= nSockBuf;                    //Subtraction takes place here.

    int nRet = send( s, p, cb, f );
    if( nRet != cb )
        return nRet;

    return cb + send( s, p+cb, nSockBuf, f );
}
				

Back to the top

Microsoft has confirmed this to be a problem in Microsoft Windows 2000.

Back to the top

These symptoms may also be present if very large buffers are supplied in this type of call without using the above workaround.

Back to the top