home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / clients / 163 < prev    next >
Encoding:
Internet Message Format  |  1992-11-08  |  1.4 KB
  1. Xref: sparky comp.client-server:163 comp.unix.large:361
  2. Newsgroups: comp.client-server,comp.unix.large
  3. Path: sparky!uunet!zaphod.mps.ohio-state.edu!wupost!decwrl!concert!rock!taco!eos.ncsu.edu!hschadha
  4. From: hschadha@eos.ncsu.edu 
  5. Subject: Re: Upper bounds of TCP & server processes in Unix
  6. Message-ID: <1992Nov8.052138.25013@ncsu.edu>
  7. Sender: news@ncsu.edu (USENET News System)
  8. Organization: North Carolina State University
  9. References:  <Bx7JGy.6BJ@gpu.utcs.utoronto.ca>
  10. Date: Sun, 8 Nov 1992 05:21:38 GMT
  11. Lines: 22
  12.  
  13. In article <Bx7JGy.6BJ@gpu.utcs.utoronto.ca>, eric@cathaus.utcs.utoronto.ca (Eric M. Carroll) writes:
  14.  
  15. |> Has anyone tried to drive this class of machine hard in a
  16. |> "connection-oriented" client/server relationship? 
  17.  
  18. I had a tough time once last year (being then a novice in the world of
  19. UNIX 4.3 BSD sockets) trying to figure out why my distributed matrix
  20. multiplication program hung up for big problems (with higher number of
  21. non-blocking calls to remote servers). Experimenting with different sizes
  22. of matrices (and blocks), I found that the problem arose after about
  23. fifty client-server stream (connection-oriented) connections.
  24.  
  25. The problem was in my leaving the sockets open, even after the client had
  26. successfully demanded the result. Yes, it was the wrong way to look for 
  27. errors. But .......
  28.  
  29. I was using TCP/IP on the DEC 2100s here.
  30.  
  31. -- 
  32.  Harpreet S. Chadha           
  33.  Graduate Student
  34.  Civil Engineering, NCSU
  35.