home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / sys / mac / programm / 14234 < prev    next >
Encoding:
Internet Message Format  |  1992-08-19  |  2.3 KB
  1. Path: sparky!uunet!newsstand.cit.cornell.edu!vax5.cit.cornell.edu!tcd
  2. From: tcd@vax5.cit.cornell.edu
  3. Newsgroups: comp.sys.mac.programmer
  4. Subject: MacTCP (UDP) questions
  5. Message-ID: <1992Aug19.173303.14543@vax5.cit.cornell.edu>
  6. Date: 19 Aug 92 17:33:03 EDT
  7. Distribution: comp
  8. Organization: Cornell University
  9. Lines: 44
  10.  
  11.      I am working on an application that needs to transfer a continuous,
  12. high volume stream of data from one Macintosh to another.   Because we
  13. can tolerate some amount of data loss/corruption it seemed like UDP
  14. would be a better choice than TCP.  I have not seen much in the way
  15. of discussion or sample code regarding UDP, and a number of questions
  16. have come up.
  17.  
  18. 1)  If I do my UDPRead calls asynchronously, where does the MacTCP driver
  19. get the time to complete them?  Is much of the processing done on the
  20. Ethernet card, or am I really just robbing Peter to pay Paul with 
  21. the async calls?
  22.  
  23. 2)  What happens if the receive buffer gets full?  Am I correct to assume
  24. that incoming packets will be discarded, or do old ones get replaced?
  25. Does the condition clear itself as soon as enough of the buffer has been
  26. returned?
  27.  
  28. 3)  Although packet order is not critical (otherwise I would use TCP), 
  29. it would be nice for my application to get access to the packets in
  30. the same order they arrive.  Can I assume that a UDPRead will return
  31. the oldest packet in the buffer?
  32.  
  33. 4)  Is there any advantage (or disadvantage) to keeping at least one
  34. UDPRead call outstanding at all times?
  35.  
  36. 5)  Where could I find the answers to these questions without asking
  37. the net?  I have a feeling that debugging/optimizing this stuff is not
  38. going to be easy, so I am trying to think this through clearly in advance,
  39. rather than just jumping in.
  40.  
  41. Finally, it seems true that, in principal, UDP is going to provide
  42. a much higher data transfer rate than TCP, as long I don't mind a little
  43. corruption.  However, I wonder how true this will actually be in 
  44. implementation on the Macintosh.  Even though I don't need the error
  45. checking and acknowledgments of TCP, I do need some flow control, 
  46. packet buffering, and some processing for partial "stream reconstitution".
  47. Is it likely that (Mac)TCP does all of this (and more) better than I could
  48. do with (Mac)UDP?  Thanks for any advice.
  49.  
  50. Tim Dorcey
  51. Cornell Information Technologies
  52. tcd@cornellc.cit.cornell.edu
  53. my implementation 
  54.    
  55.