home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / protocol / tcpip / 4304 < prev    next >
Encoding:
Text File  |  1992-09-04  |  1.8 KB  |  51 lines
  1. Newsgroups: comp.protocols.tcp-ip
  2. Path: sparky!uunet!caen!sdd.hp.com!apollo.hp.com!netnews
  3. From: sommerfeld@apollo.hp.com (Bill Sommerfeld)
  4. Subject: Re: TCP reliability
  5. Sender: usenet@apollo.hp.com (Usenet News)
  6. Message-ID: <SOMMERFELD.92Sep4151357@gourmet.apollo.hp.com>
  7. In-Reply-To: droux@hei.unige.ch's message of 4 Sep 92 16:24:58 +0200
  8. Date: Fri, 4 Sep 1992 19:13:01 GMT
  9. Lines: 37
  10. References: <1992Sep4.162458.1@hei.unige.ch>
  11. Nntp-Posting-Host: gourmet.ch.apollo.hp.com
  12. Organization: Hewlett Packard
  13.  
  14. In article <1992Sep4.162458.1@hei.unige.ch> droux@hei.unige.ch writes:
  15.  
  16.    These two entities are communicating through AF_INET family
  17.    sockets of SOCK_STREAM type. Our Problem is, that a receiver implemented on
  18.    a NeXT receives much more packets than the sender implemented on 
  19.    a Sun workstation sends (1.3 : 1).
  20.  
  21.    The data exchange is made by normal read() and write() calls followed by an 
  22.    acknowledgement. We transmitt packets of 5000 bytes of unstructered data.
  23.    If a sender send 300 packets (as a concrete example) the receiver receives
  24.    over 400 packets and about 120 of them are invalid. We consider this as a
  25.    serious problem since our system is based on realibility of TCP sockets.
  26.    Is there a special option on sockets or another method to avoid these
  27.    problems?
  28.  
  29. No, you have a fundamental misunderstanding about TCP.
  30.  
  31. TCP is byte oriented, not "record" or "packet" oriented.
  32.  
  33. With sockets, when you do a read() on a TCP socket, your process
  34. either blocks until something is available, or returns immediately
  35. having read the data immediately available (or a prefix of it, if you
  36. passed a buffer shorter than the amount queued for read).
  37.  
  38. If you want to do record-oriented things over TCP, you have to define
  39. your own record boundaries (e.g., with a byte count followed by the
  40. bytes), and count carefully on the receive end.
  41.  
  42.                     - Bill
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.