Xref: utzoo comp.os.os2.programmer:592 comp.protocols.tcp-ip:15530 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!news.cs.indiana.edu!arizona.edu!cerritos.edu!orion.oac.uci.edu!ucivax!ucla-cs!elroy.jpl.nasa.gov!sdd.hp.com! caen!hellgate.utah.edu!fcom.cc.utah.edu!npd.novell.com!newsun!colin From: colin@la.excelan.com (Colin Goldstein) Newsgroups: comp.os.os2.programmer,comp.protocols.tcp-ip Subject: Re: Problems with IBMs TCP/IP V1.1 for OS/2 Message-ID: <1991Apr4.161706.18922@novell.com> Date: 6 Apr 91 09:19:26 GMT Sender: news@novell.com ( Lines: 31 The News Manager) Nntp-Posting-Host: la Reply-To: colin@la.novell.com (Colin Goldstein) Organization: Novell, Inc., San Jose, Ca References: Date: Thu, 4 Apr 1991 16:17:06 GMT In article chlebosc@nadia.stgt.sub.org (Claudius Chlebosch) writes: >The server calls the recv() function, which returns with 4360 bytes >received. The client has to call the recv() function once again to >get the remaining 15640 >bytes of the segment. In my opinion this >behaviour is not correct. > I don't have the IBM TCP/IP package, but the TCP/IP toolkit from Novell works the same way. Although stream sockets give reliable delivery, there is no way to be sure that all the data will arrive at the same time. It is therefore the applications responsibility to recv() until all the data is read. Keep a count of bytes read or use select() to determine if more data is available. Colin -- /-------------------------------------------------------------------\ | The views expressed here are my own. | Norm, what are you | | They do not necessarily represent | up too??? | | the views expressed by my employer. | | | ---------------| My ideal weight if I | | colin@novell.com | Novell Inc., | were 11 feet tall. | | uunet!novell!colin | San Jose | - Cheers | \-------------------------------------------------------------------/