Paul Jakma wrote:
On Fri, 5 Jan 2007, Darren Reed wrote:
If one were to use the socket option SO_RCVBUF, there is an
expectation that the system will at some point fill that buffer if
there is enough data written before I do a read.
Assuming that the receive-buffer can be fully filled with user-data is
wrong. ;) Just cause there's only a few bytes in the receive buffer
does /not/ mean the receive buffer has space left. :)
As I said in my email, it may take longer, sometimes, than others
to fill, but there is an expectation that under normal conditions
that a writer can and will fill it.
This application, presuming it can also run over non-TCP-fusion, also
is assuming:
- how the system accounts non-data bytes to the receive buffer
- deeply implementation specific and un-application-relevant
When I use SO_RCVBUF, I'm specifying a read buffer size for data
to be read by my application. I would expect said buffer to be used
for my data and not protocol headers. Same for SO_SNDBUF.
This is the way it has worked ever since I started programming TCP
client/server applications. If an operating system were to decide
to do something else, I'd call that behaviour broken.
As I mentioned, this may not be the perfect mechanism to use but
it is the only one we've got. Trying to say we shouldn't rely on it
because the system might decide to use the buffers in some
strange way doesn't carry any water with me. It sounds like
someone desperately looking for a way out when they're cornered.
Even if this application is only ever meant to run on Solaris and TCP
loopback, there's no guarantee that:
- the application actually will get tcp fusion (various administrative
actions can cause fusion to be disabled, e.g. do_tcp_fusion), if it
gets TCP the buffering behaviour will be completely different again.
- that the admin won't have tweaked tcp_fusion_burst_min
Tweaking this is beyond what a developer should need to do,
forgetting the fact that they need special privileges to do this.
We document the above in Bigadmin. ;)
Or have I got the wrong end of the stick?
You do.
As Brian put it in his email, this "feature" in Solaris breaks applications
that have (and do) work flawlessly everywhere *but* Solaris 10.
Darren
_______________________________________________
networking-discuss mailing list
[email protected]
