Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!asuvax!ncar!elroy.jpl.nasa.gov!sdd.hp.com!think.com!yale.edu!cmcl2!uupsi!sunic!sics.se!uppsala.telesoft.se!uppsala.telesoft.se!thomas From: thomas@nexus.se Newsgroups: comp.protocols.tcp-ip Subject: STREAMS flow control in SunOS 4.1.1 Message-ID: Date: 27 Jun 91 09:21:00 GMT Sender: usenet@uppsala.telesoft.se Distribution: comp Organization: Communicator Nexus AB Lines: 26 I've converted an application using a TCP socket to talk to a remote process to use STREAMS instead. The communication is half duplex, the connection is established and a lot of data is sent to the remote end and a reply is expected after the remote end has consumed the data. When I've set up the connection I I_PUSH tirdwr (after I_POPing timod) to be able to use the ordinary read / write system calls. If I'm using sockets there wont be more than a few K bytes on the way before write blocks. Using STREAMS I find that write will never block, I can cram 150K down the stream without blocking. The problem is that I seem to lose the last part of the data. Also data flowing from the remote end is lost. Using a lanwatcher I can see that the last part of the data written is not transmitted and that the remote end actually sends data that is never delivered to the process. I would like the behaviour of the stream to match that of a socket. What am I missing? Is there an option that can be used on the stream that would limit the amount of data that is on the way before blocking or is it a bug in SunOS? -- Real life: Thomas Tornblom Email: t_tornblom@nexus.se Snail mail: Communicator Nexus Phone: +46 18 171814 Box 857 Fax: +46 18 696516 S - 751 08 Uppsala, Sweden