In AIR 3.x, a socket write()+flush() on a client will hang app if peer adverts TCP ZERO WINDOW

Question

In AIR 3.x, a socket write() + flush() on a client will hang (and freeze the entire app) if the socket peer advertises a ZERO TCP Window, i.e. no space available in peer receiver's socket buffer.
AIR on Windows insists that the developer flush() the socket in order to write (any data at all).  When the peer (receiver) advertises a 0 byte tcp window, the client flush() call can sometimes take 10 seconds (i.e. 10000 milliseconds), whereas normally it should take 10 to 50 milliseconds.
Additionally, AIR stayed in hung position.  Since the socket had TCP KEEPALIVE option enabled (at the server), the socket stayed open.  I let it stay hung overnight.  The next day when I rebooted the server, the socket got closed and finally the AIR program "RETURNED FROM the sock.flush()" call.  A timestamp before and after the call to flush() showed that the flush() call was in hung state for 56472475 milliseconds, i.e. 15.7 hours!  After it returned from the flush() call the AIR app was responsive and seemed to work properly.  Thus proving that it was indeed stuck (or blocked) on the flush() call for 15 hours trying to drain the data to a socket with zero tcp window condition.
A tcp zero window condition on 1 socket hanging an entire app sounds concerning.
Solution Suggestions:
(1) What is needed is for the OutputProgress event to include a field for 'bytes that can be written safely without blocking on the socket', i.e. 'space available in underlying platform socket buffer' which would account for the socket send buffer size.
(2) An alternative solution would be for AIR to provide a write-timeout setsockopt (or a writeTimeout() method on the socket), and return flush with an error (or EWOULDBLOCK), and call the OUTPUTPROG event only when there is enough space available.
If there are any other workarounds, please let me know.
Thank you.

Answer 1

Question:  Does Adobe AIR expose the getsockopt() and setsockopt() calls on a socket?  It would be useful to apps to tune the io buffer sizes.
Additional Details:
RTT = 100+ milliseconds
TCP Window Scaling enabled
Secure Socket
Hard to reproduce with plain TCP socket, but occurs without fail with SecureSocket.  Not knowing the underlying code base, am wondering if it is because the SSL encryption overhead (bytes) throws off the buffer available size compution in secure_sock.flush() .
Thanks.