ako@hutcs.hut.FI (Arto Kojo) (11/09/89)
It seems that there is a bug in TCPRecvChars XFCN in MacTCP Toolkit 1.0 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. When I read characters for example with TCPRecvUpTo, TCPCharsAvailable increases every now and then, and I finally get all those 25000 characters. So, this method works and I can read all the chars. However, reading with TCPRecvUpTo is slow, and because I know the exact number of characters, I decided to try TCPRecvChars. But 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. After TCPRecvChars exits with those 1500 chars, TCPCharsAvailable returns a number greater than zero, so there is more characters to be read.. Comments? -- :::: Arto Kojo :::::::::::::::::::::: Helsinki University of Technology :::: :: TKK/TKO-lab/Y227 ako@hutcs.hut.fi :: :: 02150 ESPOO FINLAND s29808u@puukko.hut.fi :: :::: tel: +358-0-4513236 :::::::::::: akojo@otax.tky.hut.fi ::::::::::::::::
chesley@goofy.apple.com (Harry Chesley) (11/10/89)
In article <AKO.89Nov9134953@hutcs.hut.FI> 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.