Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!apple!goofy.apple.com!chesley From: chesley@goofy.apple.com (Harry Chesley) Newsgroups: comp.sys.mac.hypercard Subject: Re: MacTCP problem Message-ID: <5101@internal.Apple.COM> Date: 9 Nov 89 18:48:54 GMT References: Sender: usenet@Apple.COM Organization: Apple Computer, Inc. Lines: 31 In article ako@hutcs.hut.FI (Arto Kojo) writes: > I have 25000 chars waiting in UNIX host. Due to some kind of > buffering, the first call of TCPCharsAvailable returns only a number > of 1500..2000. Yes, TCPCharsAvailable returns the number of characters immediately available without any waiting. I.e., the number of chars that have already been transferred to the local machine. It doesn't say how many might also be waiting at the other end of the connection. You can pass the number returned from this function to TCPRecvChars (i.e., you don't have to call TCPRecvUpTo). When you do, you're assured that it'll return right away, so you (and therefore your user) don't lose control. > TCPRecvChars(connectionID,25000) returns only the first "buffer", that is, > about 1500 chars. And it won't wait until all of the characters has been > received, as the documentation stack says. It should definitely return the full 25000, even if it has to wait for centuries to do it. Sounds like a bug to me. I'll look into it. However, are you sure you want to do that? By telling it to read the full 25000 chars, you're freezing the machine for a potentially long period. During that time, the user has no control at all. This is the sort of thing that makes users hit the reboot button. I wonder if reading the chars a buffer at a time, and in between giving the user an abort option (checking for mouse down on a Cancel button), and doing partial display of the incoming data so the user is reassured that something is happening wouldn't be a good idea.