[comp.protocols.tcp-ip] Mac TCP--Info??

asl2@tank.uchicago.edu (Aaron "Fish" Lav) (03/11/90)

What exactly is MacTCP?  Is it a released product?  Is it free?  
In general, if I want to write TCP/IP programs for the Mac and don't
want to reimplement
TCP/IP/UDP/etc myself, what's the recommended thing to do?
                              Thanks,
                              Aaron <><|
asl2@tank.uchicago.edu

hayes@Apple.COM (Jim Hayes) (03/13/90)

asl2@tank.uchicago.edu (Aaron "Fish" Lav) writes:
> What exactly is MacTCP?  Is it a released product?  Is it free?  
> In general, if I want to write TCP/IP programs for the Mac and don't
> want to reimplement
> TCP/IP/UDP/etc myself, what's the recommended thing to do?

I've posted this for others as well as Aaron instead of using E-mail.
This is not an advertisement.  This is FYI.

Officially:

	MacTCP is a software driver for the Macintosh Operating System
	that allows developers to create Macintosh applications for
	network environments that use TCP/IP.

	MacTCP is a site-licensed product for developers.  It can be 
	ordered via the Apple Software Licensing Department.

	Dunno if it costs anything.

Functionally:

	MacTCP is an implementation of TCP/IP for the native Macintosh
	OS.  It supports socketed UDP datagrams, TCP streams, ICMP
	messages, Domain Name Service (DNS) name resolution, static,
	dynamic and server based IP address assignment.   It also
	understands the "routed" routing information protocol.  It has a
	"control panel" interface.

	This is a DRIVER and not application level software.

	It is co-resident with other drivers, including AppleTalk, so you can
	use AppleTalk AND MacTCP simultaneously.

Technically:

	Programs you create that use MacTCP may pass data buffers into and
	out of the driver, or, use a scatter-gather buffer arrangement to
	eliminate buffer copying.  It uses standard driver calls like PBOpen,
	PBClose and PBControl.

	On LocalTalk (or Ethernet networks with no IP routing capabilities),
	MacTCP can encapsulate TCP/IP in AppleTalk packets for later
	decomposition at an AppleTalk/IP bridge on the destination network. 
	(I.e. Kinetics FastPath, Cayman GatorBox, etc.)

Reality:

	Writing your first program using MacTCP is like writing your first
	BSD UNIX client/server-- It hangs, it crashes, it misbehaves.  But
	once you perfect it, re-using your code is simple provided you put
	some thought into its design.

	If you are going to use it, I recommend Object Pascal or
	C++.  Make "connection objects" in which you create instances of
	TCP or UDP "connections" that have "read" and "write" methods.
	It gives you reusable code and makes good cognitive sense.  If
	you're not into objects, traditional methods work well too.


-- 
Jim Hayes, TCP/IP Weenie
Advanced Technology Group, Apple Computer Inc.

Inet: hayes@apple.com		 UUCP: {amdcad|decwrl|ames}!apple!hayes

Mats.Sundvall@bio.embnet.se (Mats Sundvall) (03/15/90)

In article <39441@apple.Apple.COM>, hayes@Apple.COM (Jim Hayes) writes:
> asl2@tank.uchicago.edu (Aaron "Fish" Lav) writes:
> Reality:
> 
> 	Writing your first program using MacTCP is like writing your first
> 	BSD UNIX client/server-- It hangs, it crashes, it misbehaves.  But
> 	once you perfect it, re-using your code is simple provided you put
> 	some thought into its design.
> 
> 	If you are going to use it, I recommend Object Pascal or
> 	C++.  Make "connection objects" in which you create instances of
> 	TCP or UDP "connections" that have "read" and "write" methods.
> 	It gives you reusable code and makes good cognitive sense.  If
> 	you're not into objects, traditional methods work well too.
> 

So, do I have to write the connection objects myself, or has anyone
done it?

> 
> -- 
> Jim Hayes, TCP/IP Weenie
> Advanced Technology Group, Apple Computer Inc.
> 
> Inet: hayes@apple.com		 UUCP: {amdcad|decwrl|ames}!apple!hayes

	Mats Sundvall
	University of Uppsala
	Sweden

rich@sendai.sendai.ann-arbor.mi.us (K. Richard Magill) (03/16/90)

Before you get your hopes up...

In article <39441@apple.Apple.COM> hayes@Apple.COM (Jim Hayes) writes:

   Functionally:

	   It is co-resident with other drivers, including AppleTalk,
	   so you can use AppleTalk AND MacTCP simultaneously.

This isn't quite true.  Somehow there are collisions on a number of
annoying things on my se30 with a dove ether board.  I don't know
whose fault they are, (maybe mine), but when using net at all, (even
over ether), you can't configure your printer port to do much of
anything.  Also, you really have to reconfigure and reboot if you want
to use a) macTCP things vs b) old style ncsaTelnet vs well, you get
the idea.

   Technically:

	   On LocalTalk (or Ethernet networks with no IP routing
	   capabilities), MacTCP can encapsulate TCP/IP in AppleTalk
	   packets for later decomposition at an AppleTalk/IP bridge
	   on the destination network.  (I.e. Kinetics FastPath,
	   Cayman GatorBox, etc.)

But not vice verse.  ie, appletalk in ip, a la kip, so you would still
need a gateway to do CAP.

csr@ubvax.UB.Com (Chris Ranch) (03/16/90)

In article <RICH.90Mar15151409@sendai.sendai.ann-arbor.mi.us> rich@sendai.ann-arbor.mi.us writes:
>Before you get your hopes up...
>
>In article <39441@apple.Apple.COM> hayes@Apple.COM (Jim Hayes) writes:
>
>   Functionally:
>
>	   It is co-resident with other drivers, including AppleTalk,
>	   so you can use AppleTalk AND MacTCP simultaneously.
>
>This isn't quite true.  Somehow there are collisions on a number of
>annoying things on my se30 with a dove ether board.  I don't know
>whose fault they are, (maybe mine), but when using net at all, (even
>over ether), you can't configure your printer port to do much of
>anything.  Also, you really have to reconfigure and reboot if you want
>to use a) macTCP things vs b) old style ncsaTelnet vs well, you get
>the idea.

I must say that you can have MacTCP _AND_ AppleTalk operate concurrently
at full speed.  This is the way it's designed.  Personally I've tried,
successfully, to be downloading a file from applelink using a Shive Netmodem,
logged on to 3 different IP hosts over MacTCP, 'cat'ting big files to the
emulation windows, and printing BIG files to a laserwriter, all at the
same time at reasonable performance.  This is with Apple's EtherTalk card,
AppleTalk configured to EtherTalk Phase 2, and MacTCP configured to use
the Ethernet directly.

Well written software should do this.

Regards,


-- 
Chris Ranch
Ungermann-Bass, Inc
(408)562-7957      csr@ubvax.ub.com

hayes@Apple.COM (Jim Hayes) (03/16/90)

This topic is being moved to comp.sys.mac.programmer.  My apologies
for wasting comp.protocols.tcp-ip bandwidth.

rich@sendai.ann-arbor.mi.us writes:
>Before you get your hopes up...
>
>In article <39441@apple.Apple.COM> hayes@Apple.COM (Jim Hayes) writes:
>
>   Functionally:
>
>	   It is co-resident with other drivers, including AppleTalk,
>	   so you can use AppleTalk AND MacTCP simultaneously.
>
>This isn't quite true.  Somehow there are collisions on a number of
>annoying things on my se30 with a dove ether board.  I don't know
>whose fault they are, (maybe mine), but when using net at all, (even
>over ether), you can't configure your printer port to do much of
>anything.  Also, you really have to reconfigure and reboot if you want
>to use a) macTCP things vs b) old style ncsaTelnet vs well, you get
>the idea.

1) Printer port problems:  Check with Dove.  My guess is that it's their
   driver doing it.  We havn't seen those problems.  The EtherTalk driver 
   allows attaching and detaching of protocol handlers (based on the "type"
   field in the packet) to the card so multiple protocols can be processed
   simultaneously.
2) NCSA Telnet 2.3 supports MacTCP.  Earlier versions of NCSA Telnet
   do not follow Apple's guidelines for accessing the EtherTalk driver and
   as such may interfere with MacTCP, AppleTalk, etc.

>   Technically:
>
>	   On LocalTalk (or Ethernet networks with no IP routing
>	   capabilities), MacTCP can encapsulate TCP/IP in AppleTalk
>	   packets for later decomposition at an AppleTalk/IP bridge
>	   on the destination network.  (I.e. Kinetics FastPath,
>	   Cayman GatorBox, etc.)
>
>But not vice verse.  ie, appletalk in ip, a la kip, so you would still
>need a gateway to do CAP.

1) It works both ways.  The Kinetics FastPath will RE-ENCAPSULATE IP back
   into AppleTalk so it may return to the source.  
2) CAP does not require "gateways" (what the author defines as a gateway)
   because it looks like an ordinary AppleTalk device.


-- 
Jim Hayes, TCP/IP Weenie
Advanced Technology Group, Apple Computer Inc.

Inet: hayes@apple.com		 UUCP: {amdcad|decwrl|ames}!apple!hayes