home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / sys / next / programm / 6004 < prev    next >
Encoding:
Text File  |  1992-09-07  |  2.6 KB  |  67 lines
  1. Newsgroups: comp.sys.next.programmer
  2. Path: sparky!uunet!haven.umd.edu!ni.umd.edu!sayshell.umd.edu!louie
  3. From: louie@sayshell.umd.edu (Louis A. Mamakos)
  4. Subject: Re: TCP reliability on NeXT
  5. Message-ID: <1992Sep5.135747.20758@ni.umd.edu>
  6. Sender: usenet@ni.umd.edu (USENET News System)
  7. Nntp-Posting-Host: sayshell.umd.edu
  8. Organization: University of Maryland, College Park
  9. References: <1992Sep4.163219.1@hei.unige.ch>
  10. Date: Sat, 5 Sep 1992 13:57:47 GMT
  11. Lines: 54
  12.  
  13. In article <1992Sep4.163219.1@hei.unige.ch> droux@hei.unige.ch writes:
  14. >
  15. >TCP/IP BERKELEY SOCKETS: Transmission problems with doublicated packets
  16. >-----------------------------------------------------------------------
  17.  
  18. You omitted the most interesting code of call: that which does read() and
  19. write().
  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. You are mistaken if you believe that TCP maintains any record
  30. boundaries when you preform a write() or read() system call.  It does
  31. not.  It is a stream protocol.  When you perform a read() system call,
  32. it will return to you the number of octets of data returned to you
  33. which may be different than the size of your buffer.  Thus, of the
  34. sending application writes 5000 bytes and the receiving application
  35. does a series of reads, it could return 3000 bytes on one read
  36. followed by 2000 bytes on a subsequent one.
  37.  
  38. I am aware of no bugs in this area relating to TCP and the reliablity
  39. of the data being transmitted.
  40.  
  41. >Special Comments:
  42. >1. If the server and the client are running on the same computer, the problem
  43. >   does not occur.
  44.  
  45. Of course it will act differently, as everything is effectively happening
  46. synchronously since you are never leaving the machine.
  47.  
  48. >2. If the NeXT (receiver client) is swapping the number of faulty packets is
  49. >   increasing.
  50.  
  51. Again, probably timing related.
  52.  
  53. >3. The number of faulty packets is somehow depending on their size.
  54.  
  55. How do you know the "packet" are faulty?  Remember, the user interface
  56. to TCP has no notion at all of "packets", just streams of data.  It is
  57. very similar to a tty-type device in that respect.
  58.  
  59. >We would be very happy about some information as our application is part
  60. >of our graduation thesis.
  61.  
  62. You should investigate a very good book: "UNIX Network Programming" by
  63. Stevens.  It covers this material quite well.
  64.  
  65. louie
  66.  
  67.