Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!decwrl!sgi!shinobu!odin!hwajin From: hwajin@sgi.com (Hwa-jin Bae) Newsgroups: comp.protocols.tcp-ip Subject: Re: STREAMS flow control in SunOS 4.1.1 Message-ID: <1991Jun28.090418.13395@odin.corp.sgi.com> Date: 28 Jun 91 09:04:18 GMT References: Sender: news@odin.corp.sgi.com (Net News) Reply-To: hwajin@pei.com Distribution: comp Organization: Protocol Engines, Inc. Lines: 39 In-Reply-To: thomas@nexus.se's message of 27 Jun 91 09: 21:00 GMT >>>>> On 27 Jun 91 09:21:00 GMT, thomas@nexus.se said: thomas> When I've set up the connection I I_PUSH tirdwr (after thomas> I_POPing timod) to be able to use the ordinary read / write thomas> system calls. If I'm using sockets there wont be more than a thomas> few K bytes on the way before write blocks. it's not clear what's meant by "blocking" here but if you're refering to a case where the call to write() blocks when socket level buffer is full you can get around the problem by setsockopt()'ing with larger number for socket level buffers. the size available depend on the upper limit for the amount of mbuf your kernel allowed for such allocation. some systems have limit set to 64K even though the default size of socket level buffer for a given protocol is set to much smaller "a few" K bytes. thomas> Using STREAMS I find that write will never block, I can cram thomas> 150K down the stream without blocking. The problem is that I thomas> seem to lose the last part of the data. Also data flowing from thomas> the remote end is lost. Using a lanwatcher I can see that the thomas> last part of the data written is not transmitted and that the thomas> remote end actually sends data that is never delivered to the thomas> process. since the tirdwr simply calls tpi multiplexor in most implementations, and hands over STREAMS msg to put routine of the tpimux, and tpimux has its own write-put-service routine, data loss at the STREAMS msg queue between modules is probably unlikely. sounds like a protocol implementation strangeness... a few things to check: 1) how many bytes are not delivered, 2) anything still queued at the socket on the sending side? (use netstat), 3) does write() return successfully, 4) check tcp window sizes (sender might be zero win probing) using your analyzer, 5) check # of bytes not received on the receive side and the contents, 6) look at the contents of last 20 or so tcp segments snooped via the net analyzer. *hwajin -- protocol engines, inc.