I think that you are out of luck.

The Windows platform setsockopt docs don't explicitly mention this option in the table of "BSD options not supported for setsockopt are shown in the following table." about half way down the page.

However, if you look at the equivalent table for getsockopt, it is explicitly listed as unsupported.

That said, and without any knowledge of how this stuff works on *nix/BSD et al, I think that you are being naive to believe that setting the maximum segment size in the receiving application is going to have any affect at all on how much the sending application will choose to buffer.

My (limited) understanding of how this stuff works is that the TCP_MAXSEG has little or nothing to do with Application Layer(1) or Session layer(3) of the OSI stack which is where buffering occurs, but is at the Transport Layer(4). Meaning that it's value affects all communications between this end point and the down stream node, and is therefore a TDI layer configuration option, not a dynamic runtime option. It should only be configured on the basis of the type of pipe between nodes:ie. Dial-Up Modem -v- Cable Modem -v- PPPoE -v- ADSL/HDSL/VDSL -v- ISDN -v- Kilostream -v- Megastream etc.

If you could change it change it dynamically from an application, it would affect all communications from this end point and it's upstream partners--which seems like a bad idea to me.

I think it could be a bit of TheWildgoose chase :)