home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / unix / programm / 4545 < prev    next >
Encoding:
Internet Message Format  |  1992-09-07  |  3.0 KB
  1. Xref: sparky comp.unix.programmer:4545 comp.protocols.tcp-ip:4315
  2. Newsgroups: comp.unix.programmer,comp.protocols.tcp-ip
  3. Path: sparky!uunet!mcsun!sunic!ugle.unit.no!Steinar.Haug
  4. From: Steinar.Haug@delab.sintef.no (Steinar Haug)
  5. Subject: Re: TCP reliability
  6. In-Reply-To: droux@hei.unige.ch's message of 4 Sep 92 16:35:05 +0200
  7. Message-ID: <STEINAR.HAUG.92Sep5115614@delab.sintef.no>
  8. Sender: news@ugle.unit.no (NetNews Administrator)
  9. Organization: SINTEF DELAB, Trondheim, Norway.
  10. References: <1992Sep4.163505.1@hei.unige.ch>
  11. Date: 5 Sep 92 11:56:14
  12. Lines: 50
  13.  
  14. > We are currently implementing a distributed system providing the use of
  15. > different computers (different UNIX workstations) connected by Internet.
  16. > Our System is based on a server - client model using berkeley sockets.
  17. > 
  18. > These two entities are communicating through AF_INET family
  19. > sockets of SOCK_STREAM type. Our Problem is, that a receiver implemented on
  20. > a NeXT receives much more packets than the sender implemented on 
  21. > a Sun workstation sends (1.3 : 1).
  22. > 
  23. > As TCP is known as sequenced, reliable and two-way connection based, this
  24. > fact is surprising to us. Is it possible to avoid this ? 
  25.  
  26. Yes, TCP is sequenced and reliable. But it does *not* provide "record" (i.e.
  27. packet) boundaries which are visible to the application. You must build these
  28. on top of TCP yourself if you need them. (Or you could use UDP, which *will*
  29. allow you to preserve packet boundaries - but then you must build the
  30. necessary reliability yourself on top of UDP. Much easier to make a small
  31. layer on top of TCP which does what you want.)
  32.  
  33. The operating system is free to turn one or more of your write() calls into
  34. as many packets as it sees fit. I.e.,
  35.  
  36. - one write call may turn into many packets (write 50000 bytes and you will
  37.  get approx. Ethernet 34 packets)
  38.  
  39. - many write calls may turn into one packet (call write many times with 1 byte
  40. buffers, and the OS will probably try to coalesce your writes into bigger
  41. packets)
  42.  
  43. Similarly, on the receiving side, each read() may return less data than you
  44. asked for - this is also perfectly acceptable.
  45.  
  46. > The data exchange is made by normal read() and write() calls followed by an 
  47. > acknowledgement. We transmitt packets of 5000 bytes of unstructered data.
  48. > If a sender send 300 packets (as a concrete example) the receiver receives
  49. > over 400 packets and about 120 of them are invalid. We consider this as a
  50.  
  51. I'm not sure I understand what you mean by saying "120 of them are invalid".
  52. Could you be more specific? In the first place, what do you mean by a packet?
  53. Is it one write() call, or is it for instance an Ethernet packet? From your
  54. description it sounds more like one write() call.
  55.  
  56. TCP *is* reliable, if correctly implemented. I have used TCP on Suns for
  57. years, and it works just fine. I have no reason to believe that it does not
  58. work correctly on the NeXT...
  59.  
  60. Steinar Haug, system/networks administrator
  61. SINTEF DELAB, University of Trondheim, NORWAY
  62. Email: Steinar.Haug@delab.sintef.no, 
  63.     sthaug@idt.unit.no, steinar@tosca.er.sintef.no
  64.