home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / unix / programm / 3894 < prev    next >
Encoding:
Text File  |  1992-07-24  |  1.3 KB  |  33 lines
  1. Newsgroups: comp.unix.programmer
  2. Path: sparky!uunet!munnari.oz.au!manuel!coombs!avalon
  3. From: avalon@coombs.anu.edu.au (Darren Reed)
  4. Subject: Re: TCP/IP connections, how does the blocking work?
  5. Message-ID: <avalon.711995190@coombs>
  6. Lines: 22
  7. Sender: news@newshost.anu.edu.au
  8. Organization: Computer Services Centre, Australian National University
  9. References: <13700@mindlink.bc.ca>
  10. Date: 24 Jul 92 16:26:30 GMT
  11.  
  12. Frank@mindlink.bc.ca (Frank I. Reiter) writes:
  13.  
  14. >I am considering moving relatively large amounts of data from a fast
  15. >originating process on one machine, to a relatively slow receiving process on
  16. >another machine via sockets.
  17.  
  18. >If the originating process attempts to write a few megabytes more than the
  19. >receiving process has read, will it block, what causes it to block, and how far
  20. >ahead is it likely to get before it does block?
  21.  
  22. >I want to make sure I will not be placing undo stress on the receiving machine
  23. >by causing it to try to buffer data not yet read by the process it is intended
  24. >for.  Can the receiving machine cause the sending machine to cause the sending
  25. >process to block?
  26.  
  27. Yes it can and will block when the receiving buffer's are full.
  28. On SunOS this is around 4 or 8 kbytes in size by default.
  29. Use setsockopt and getsockopt to manipulate the buffer sizes using the
  30. appropriate options (SO_SNDBUF/SO_RCVBUF).
  31.  
  32. Darren
  33.