Path: utzoo!attcan!utgpu!watmath!maytag!aries5!jb From: jb@aries5.uucp Newsgroups: comp.protocols.appletalk Subject: Re: ATP timeouts Message-ID: <674@maytag.waterloo.edu> Date: 20 Oct 89 14:59:25 GMT References: Sender: daemon@maytag.waterloo.edu Reply-To: jb@aries5.UUCP () Organization: Computer Systems Group, University of Waterloo Lines: 40 In article BSCHMIDT@bnr.ca (Ben Schmidt, B.T.) writes: >Stan Duten, c11234@d1.dartmouth.edu writes: >> PS. Many thanks to Jim Bruyn, Computer Systems Group, University of >> Waterloo for the ResEdit location of the Broadcast retry interval. > >can you share this information with info-appletalk? many thanks, >Ben Schmidt Information Systems/BNR Bitnet: bschmidt@bnr.ca Each chooser RDEV has a 'GNRL' resource #-4096 consisting of two bytes the first byte is the retry interval (timeout interval) and the second byte is the retry count. Note increasing the retry interval will increase the time that it will take to close the Chooser window. Maybe Stan Duten can give us some ideas of what timeout intervals and retry counts seem to work for him. You may wish to customize this for different speeds of lines. Somebody else asked a question about how to not have the checkboxes show up in the list of AppleShare volumes so that users cannot automatically select them for mount at boot time. The solution that I gave him was to modify the list rectangle. In PACK resource #-4096 change the following rectangles: 003b 0032 007b 0123 003a 0031 007c 0133 I tried 003b 0032 007b 00f3 003a 0031 007c 0103 Which seemed to hide the check boxes. The first rectangle is the list rectangle and the second is the frame rectangle. The check boxes are drawn by the AppleShare PACK resource. I did not have enough AppleShare volumes to know if this interfered with scrolling. Could somebody provide me with a recommended way for determing timeouts on a network. We have developed our own networking software for the Mac. My original thought was I can have 32 users waiting for the server to reply, the server can send back to each of these users 8 packets each taking app. 20 msec and the server needs app. 50 msec to process the request so I need a timeout of 32*(8*20+50) = 7 sec. However if there are errors this is very very slow for the users. Any suggestions? Thanks Jim Bruyn Computer Systems Group University of Waterloo