Paul Jakma writes: > 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. :) > > 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 > - in how many packets the data is transferred possibly (not > deterministic, even if the app /does/ know exactly how the system > buffers) > > 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 > > We document the above in Bigadmin. ;) > > Or have I got the wrong end of the stick? >
I think so. :-) While I don't think an application can count of having every last byte of a socket buffer filled, in the absence of memory pressure, I fail to grasp why Solaris would not do it's best effort to come close to that. Also, if the reader goes out to lunch, I would still attempt to fill the receive socket buffer and the transmit socket buffer _before_ blocking transmitters. Do I get this right also that the need to yield the CPU is only present on single CPU systems (a rare thing these days). -r > regards, > -- > Paul Jakma, > Network Approachability, KISS. Sun Microsystems, Dublin, Ireland. > http://opensolaris.org/os/project/quagga tel: EMEA x19190 / +353 1 819 9190 > > _______________________________________________ > networking-discuss mailing list > [email protected] _______________________________________________ networking-discuss mailing list [email protected]
