home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / lang / cplus / 16161 < prev    next >
Encoding:
Internet Message Format  |  1992-11-12  |  2.5 KB
  1. Path: sparky!uunet!airgun!airgun.wg.waii.com!bab
  2. From: bab@se39.wg2.waii.com (Brian Button)
  3. Newsgroups: comp.lang.c++
  4. Subject: Problem defining underflow for Tcp streambuf class
  5. Message-ID: <BAB.92Nov12095209@se39.wg2.waii.com>
  6. Date: 12 Nov 92 14:52:09 GMT
  7. Sender: news@airgun.wg.waii.com
  8. Organization: Western Geophysical Exploration Products
  9. Lines: 42
  10. Nntp-Posting-Host: se39.wg2.waii.com
  11.  
  12. I'm having a problem defining the return codes from the underflow
  13. function for a Tcp streambuf class I've written.
  14.  
  15. The problem is that underflow only returns one of two conditions,
  16. either a read failure or the first char successfully read. This works
  17. if the data being read is static, but if new data is coming in all the
  18. time, there seems to be a third case to be handled. It is possible
  19. that there is no data available to be read now, but there will be in
  20. the future.
  21.  
  22. The problem I had arose using sbumpc(). When data was available in the
  23. get area, it was read and returned. When no data was already in the
  24. get area, underflow was called to read it, which it did, provided
  25. there was data available. If there wasn't, underflow was returning the
  26. first character available in the get area, which was put there by the
  27. previous read. The net effect of this was to have that character
  28. returned to me every time I called underflow until something else came
  29. available on the socket.
  30.  
  31. One way to handle this is to make underflow return EOF if nothing is
  32. available on the socket. This would detect this case for us, and allow
  33. us to use clear() to recover and check the socket later with another
  34. call to sbumpc or whatever. The problem with this is that it would not
  35. let us detect the difference between a no-data failure and a
  36. socket-closed failure, from which there is no recovery.
  37.  
  38. Does anyone out there in net.land have any suggestions about this? I
  39. have described it as a Tcp problem, but it really is more generic than
  40. that, dealing with all cases in which data is received dynamically and
  41. sporadically.
  42.  
  43. Thanks,
  44.  
  45. bab
  46. --
  47. |-----------------------|----------------------------------------------------|
  48. | Brian Button          | email : button@wg2.waii.com                        |
  49. | Design Engineer       |         71023.276@compuserve.com                   |
  50. | Western Geophysical   | voice : (713)964-6221                              |
  51. | 3600 Briarpark        |----------------------------------------------------|
  52. | Houston, Texas  77042 |                  Opinions Be Mine!!                |
  53. |-----------------------|----------------------------------------------------|
  54.