[comp.sys.mac.comm] Comm Toolbox TCPtool documentation

kevinh@cmi.com (Kevin Hegg) (03/15/91)

I am developing a networked application and considering whether to use the 
Comm Toolbox or not. I would like to be able to support ADSP or TCP/IP. I 
have the 1.0 documentation, but it doesn't say anything about the TCPtool. 
Is there any documentation on the TCPtool other than whats in the MacX 
documentation? Are there any known problems when developing an application to use the TCPtool?


Kevin Hegg, EDS Corp - Center for Machine Intelligence
2001 Commonwealth Blvd., Ann Arbor, Michigan 48105
Phone: (313) 995-0900  Internet: kevinh@cmi.com   Applelink: D5990

dorner@pequod.cso.uiuc.edu (Steve Dorner) (03/15/91)

In article <9263@etsu.CMI.COM> kevinh@cmi.com (Kevin Hegg) writes:
>I am developing a networked application and considering whether to use the 
>Comm Toolbox or not. I would like to be able to support ADSP or TCP/IP.

I would suggest you make your application switchable between MacTCP
and the Comm Toolbox.  This will save your MacTCP users from having to
deal with the Comm Toolbox until a few more kinks get ironed out.
--
Steve Dorner, U of Illinois Computing Services Office
Internet: s-dorner@uiuc.edu  UUCP: uunet!uiucuxc!uiuc.edu!s-dorner

bschmidt@bnr.ca (Ben Schmidt (BNR)) (03/15/91)

In article <9263@etsu.CMI.COM> kevinh@cmi.com (Kevin Hegg) writes:
> I am developing a networked application and considering whether to use 
> the Comm Toolbox or not. I would like to be able to support ADSP or TCP/IP. 
> I have the 1.0 documentation, but it doesn't say anything about the  
> TCPtool.  Is there any documentation on the TCPtool other than whats in the  
> MacX documentation? Are there any known problems when developing an 
> application to use the TCPtool?

Kevin, the response I've always got from Apple is that their TCPTool is
intended *only* for MacX.  If you want to use the CTB *and* MacTCP, you're
supposed to go 3rd party, for the interconnection tool.  That's good for 
hardworking developers like InterCon or ASC.  But it's disappointing if you
were expecting an Apple-supplied solution to interconnect Apple's CTB with
Apple's MacTCP driver.

Ben Schmidt       Information Technology,   Bell-Northern Research
bschmidt@bnr.ca   FAX:(613) 763-3283  /* My opinions, not BNR's */     

dorner@pequod.cso.uiuc.edu (Steve Dorner) (03/16/91)

>Thanks for the response. Do you have any specific stories about the 
>"kinks" in Comm Toolbox.

I knew this was coming.

Let me say up front that I think the Comm Toolbox is an interesting
attempt to solve a hard problem.  I don't think the people who are
working on it are fools or idiots; I just don't think they've quite
gotten there yet.

Let me also say that my primary experience with the Comm Toolbox
involves the Apple Modem Tool, which is not terribly successful.
It's hard for me to know which bugs are really AMT bugs, and which
are really CTB bugs.  Perhaps little of this would apply to a TCP
connection tool.

1. The Apple Modem Tool misunderstands a wide variety of modems.
Sometimes this results in crashes, sometimes in refusal to make
connections.  Hidden features often (but not always) allow this to
be rectified.  These features are not documented.

2. The CTB allows you to choose whether it should report errors,
or allow your program to do so.  Unfortunately, one is never sure
just WHICH errors the CTB will report, and which it will not.
Furthermore, some tools (AMT again) will report status to the user
(dialing, retrying, etc.).  Turning off CTB error reporting turns
off these helpful status messages, too.  You can't say, "give the
user status messages but not error messages".  This is one symptom
of a broader problem; lack of fine control over what goes on.
You're pretty much stuck with how the tools behave.

3. The AMT (again) behaves differently when used synchronously or
asynchronously on some operations.  I've finally had to go to
synchronous opens and closes to avoid problems with some modems.
Apple can't reproduce the problem (they probably don't have the
right modem to do so).

4. MacTCP has SendWDS, which has spoiled me forever.  (It allows
you to send an array of pointers to MacTCP, and have the whole
bundle sent; very efficient.)  Yes, you could duplicate the behavior
with my own subroutines, but then you lose efficiency.  (Would
whoever put the wds stuff in MacTCP wander around Apple and convince
people to add them to the File manager and the CTB?  Thank you.)

5. The CTB documentation is very, very superficial.  It is possible
that I could fix or work around some problems, if I knew a little
more about the guts of the CTB and its tools.  Unfortunately, the
dox are very short on guts (but they have lots of really nice
pictures).  For example, you're encouraged to call CMIdle when
you have a connection open; should you call it when you have
an asynch open pending?  The dox are silent.

Now, an argument could be made that some of these things are
FEATURES; that my program doesn't need to know or control the gory
details, and that the whole point of the CTB is to present simple,
abstract connections to applications, and hide all the messy stuff
inside.  That would be just fine if it worked.  It currently does
NOT.

Finally, it's possible that I'm using the darn thing wrong.  I don't
know how that could be, but I've made mistakes once or twice before.
However, if it's my fault, then I'm not happy with the documentation,
cause I sure can't figure out what I'm doing wrong.

In summary, I think it's pretty easy to do a nice, efficient, robust
connection with MacTCP.  It's much harder with the CTB (at least
where some tools are concerned).  I think the extra speed and stability
makes it worth going the extra mile for MacTCP users.
--
Steve Dorner, U of Illinois Computing Services Office
Internet: s-dorner@uiuc.edu  UUCP: uunet!uiucuxc!uiuc.edu!s-dorner

francis@zaphod.uchicago.edu (03/17/91)

In article <1991Mar15.133106.10588@bwdls61.bnr.ca> bschmidt@bnr.ca (Ben Schmidt (BNR)) writes:

   Kevin, the response I've always got from Apple is that their TCPTool is
   intended *only* for MacX.  If you want to use the CTB *and* MacTCP, you're
   supposed to go 3rd party, for the interconnection tool.  That's good for 

Do you know of any 3rd-party outfit that's done this?
--
/============================================================================\
| Francis Stracke	       | My opinions are my own.  I don't steal them.|
| Department of Mathematics    |=============================================|
| University of Chicago	       | Until you stalk and overrun,	     	     |
| francis@zaphod.uchicago.edu  |  you can't devour anyone. -- Hobbes 	     |
\============================================================================/

han@Apple.COM (Byron Han) (03/21/91)

In article <9288@etsu.CMI.COM> kevinh@cmi.com (Kevin Hegg) writes:
>In article <19357@ux1.cso.uiuc.edu>  dorner@pequod.cso.uiuc.edu (Steve 
>Dorner) writes:
>> I would suggest you make your application switchable between MacTCP
>> and the Comm Toolbox.  This will save your MacTCP users from having to
>> deal with the Comm Toolbox until a few more kinks get ironed out.
>
I would strongly urge you to get some info on the TCP/IP connection tools
that different folks put out (like the advanced software concepts TCPack tool)

CommToolbox is not perfect - it is an evolving product that is constantly 
being improved.  But it does provide a solid developer base platform
for different applications to be built upon - like MacX, MacTerminal, 
Versaterm, PacerTerm, the terminal tools (TTY, VT102, VT320, IBM 3278), 
file transfer tools (Text, XMODEM, KERMIT, ZMODEM), connection tools 
(Serial, Modem, ADSP, LAT, DECNet, SNA, X.25, TCP/IP)


-- 
Byron Han, CommToolbox Emir       Changing the world, one connection at a time
Apple Computer, Inc.              --------------------------------------------
20525 Mariani Ave, MS: 35CP       Internet: han@apple.COM
Cupertino, CA 95014               UUCP:{sun,voder,nsc,decwrl}!apple!han
ATTnet: 408-974-6450              Applelink:HAN1   HAN1@applelink.apple.COM