Tom, I agree this is entirely a client-side issue. Regardless, as Simon says it would be useful to have some documentation for client implementors.
Sehrope, thanks for the JDBC link! I was actually thinking of going about it another way in Npgsql:
- Send messages normally until the first Execute message is sent.
- From that point on, socket writes should simply be non-blocking. As long as buffers aren't full, there's no issue, we continue writing. The moment a non-blocking write exits because it would block, we transfer control to the user, who can now read data from queries (the ADO.NET.API allows for multiple resultsets).
- When the user finishes processing the resultsets, control is transferred back to Npgsql which continues sending messages (back to step 1).
This approach has the advantage of not caring about buffer sizes or trying to assume how many bytes are sent by the server: we simply write as much as we can without blocking, then switch to reading until we've exhausted outstanding data, and back to writing. The main issue I'm concerned about is SSL/TLS, which is a layer on top of the sockets and which might not work well with non-blocking sockets...
Any comments?
Shay