home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / sys / mac / programm / 21933 < prev    next >
Encoding:
Internet Message Format  |  1993-01-22  |  5.0 KB
  1. Path: sparky!uunet!cs.utexas.edu!uwm.edu!linac!att!news.cs.indiana.edu!bsu-cs!news.nd.edu!bach!dwalton1
  2. From: dwalton1@bach.helios.nd.edu (david walton)
  3. Newsgroups: comp.sys.mac.programmer
  4. Subject: ulpTimeout problems with MacTCP
  5. Summary: Can't find cause of ulpTimeouts on TCPSend.
  6. Keywords: TCP/IP MacTCP TCPSend timeout ulptimeout
  7. Message-ID: <1993Jan21.233037.25822@news.nd.edu>
  8. Date: 21 Jan 93 23:30:37 GMT
  9. Sender: dwalton1@bach.helios.nd.edu
  10. Organization: OUC, University of Notre Dame
  11. Lines: 91
  12.  
  13. I could use some help from anyone who's had experience working with
  14. TCP/IP protocols and programming with MacTCP in particular.
  15.  
  16. I'm writing a Macintosh server application that uses NNTP (Network
  17. News Transfer Protocol) to send news stories from an electronic
  18. newsfeed to a UNIX host over a TCP/IP network.  As an extension to
  19. NNTP, I've added a command that lets the client receive multiple
  20. articles with one request, with termination lines (\r\n.\r\n) added to
  21. delimit the stories in the stream.  Rather than sending the data all
  22. at once, I send a predetermined chunk each time through the event
  23. loop; the current maximum is 4K.  I also check the receive window on
  24. the remote TCP, and if it's smaller than 4K, I send however many bytes
  25. it says it's willing to take.
  26.  
  27.  
  28. The problem I'm having is that ulp (upper layer protocol) timer
  29. expires on TCPSends.  The client will issue a request, the server will
  30. chunk along sending data for a while, and then the ulp timer will
  31. expire on a particular send, and everything will hang up.  The
  32. asynchronous notification routine that I've registered with TCPCreate
  33. gets called, reports a ulp timeout, the timer restarts as expected,
  34. and the whole process repeats itself ad infinitum.
  35.  
  36. I've tried to isolate the cause of the timeouts to no avail.  I'm
  37. assuming that my server isn't getting ACKed for a batch of data sent
  38. to the client.  Problem is, I don't know why.  The connection doesn't
  39. appear to have dropped.  Some hypotheses I've investigated:
  40.    
  41. *  Client gets swamped with data.  Well, yes, but how?  The transfer
  42.    rates average around ~.75K/second--not blindingly fast.  Besides
  43.    which, changing the send buffer size to smaller numbers doesn't
  44.    have a consistent effect either way.
  45.  
  46.    I've also changed the size of the buffers supplied to TCP (though I
  47.    can't see why this would help, since the supplied buffers are used
  48.    to store *incoming* data).  Used sizes ranging from 4 to 128K.
  49.    Didn't help.
  50.  
  51. *  Processor time.  When I'm running both client and server on the same
  52.    machine, the timer expires more consistently if the server's in the
  53.    foreground and the client's in the background, suggesting that the
  54.    relative amount of processor time was the variable.  Trouble is,
  55.    reversing the two doesn't eliminate the problem; changing
  56.    sleepTicks in WaitNextEvent doesn't eliminate the problem; and
  57.    moving the client to a different machine (even using Telnet on a
  58.    UNIX box) doesn't eliminate the problem.
  59.  
  60. *  Network traffic.  This would be an obvious suggestion, except that I
  61.    do much of my testing on my IIci at home, which has no actual
  62.    physical network connection.  Moreover, I've used all varieties of
  63.    LocalTalk and Ethernet networks, both lightly- and heavily-loaded.
  64.    My testing hasn't revealed consistent differences.
  65.  
  66. Having failed to find the problem, I have two questions:
  67.     
  68. 1.  Anyone have any idea why these timeouts might be happening?  Or
  69.     could somebody explain generally what conditions might prevent
  70.     MacTCP from sending data (or receiving an ACK for it)?
  71.  
  72. 2.  Can I do anything from the Aynchronous Notification Routine to see
  73.     that the data does get sent?  I.e., something like this: ulp timer
  74.     expires, my routine gets called, routine does something magical
  75.     that gets the data delivered?  As of now, all that happens is that
  76.     the ulp timer is reset and times out repeatedly, which isn't a
  77.     very helpful behavior.
  78.  
  79. If anyone has any insights that might help here (or knows of an M that
  80. I might go RTF :-), please send me electronic mail.  Unfortunately, my
  81. familiarity with TCP doesn't extend to a very low level, so I may be
  82. missing something basic that I should know about; please tell me if so.
  83.  
  84. Finally, here's a description of my testing configurations:
  85.  
  86. * Machines: Macintosh IIci, SE/30, Quadra 700, SE, Classic.
  87. * OS:        System 7.0, 7.0*, 7.0.1, 7.0.1*, 7.1.
  88. * MacTCP:   1.1.1
  89. * Networks: Ethernet (Thin, TP), LocalTalk.  Have also used my IIci at
  90.             home which has no physical network attached.  Have tested
  91.             with client and server both on same and on different
  92.             machines for all networks.
  93. * Clients:  NCSA Telnet 2.3, 2.4.x, 2.5 for the Macintosh; Telnet for
  94.             SUN OS 4.0.x (?), custom-designed Hypercard stack. 
  95.  
  96.  
  97. Any suggestions will be rewarded with gushing replies of thanks.  :-)
  98.  
  99. David Walton
  100. --
  101. {  David Walton        Mail to dwal@midway.uchicago.edu  }
  102. {  These opinions are all mine, and the University of Notre  }
  103. {  Dame has no right (and probably no desire) to claim 'em.  }
  104.