AppleTalk

AppleTalk es un conjunto patentado de protocolos de red desarrollado por Apple Computer para sus computadoras Macintosh. AppleTalk incluye una serie de características que permiten que las redes de área local se conecten sin configuración previa o sin la necesidad de un enrutador o servidor centralizado de ningún tipo. Los sistemas equipados con AppleTalk conectados asignan automáticamente direcciones, actualizan el espacio de nombres distribuido y configuran cualquier enrutamiento entre redes necesario.

AppleTalk se lanzó en 1985 y fue el protocolo principal utilizado por los dispositivos Apple durante las décadas de 1980 y 1990. También se lanzaron versiones para IBM PC y compatibles y Apple IIGS. La compatibilidad con AppleTalk también estaba disponible en la mayoría de las impresoras en red (especialmente las impresoras láser), algunos servidores de archivos y varios enrutadores.

El auge de TCP/IP durante la década de 1990 condujo a una reimplementación de la mayoría de estos tipos de soporte en ese protocolo, y AppleTalk dejó de ser compatible a partir del lanzamiento de Mac OS X v10.6 en 2009. Muchos de AppleTalk' Desde entonces, se han introducido funciones de configuración automática más avanzadas en Bonjour, mientras que Universal Plug and Play satisface necesidades similares.

Historia

AppleNet

Después del lanzamiento de la computadora Apple Lisa en enero de 1983, Apple invirtió un esfuerzo considerable en el desarrollo de un sistema de red de área local (LAN) para las máquinas. Conocido como AppleNet, se basaba en la pila de protocolos Xerox XNS, pero se ejecutaba en un sistema de cable coaxial personalizado de 1 Mbit/s en lugar del Ethernet de 2,94 Mbit/s de Xerox. AppleNet se anunció a principios de 1983 con una introducción completa al precio objetivo de $ 500 para tarjetas AppleNet enchufables para Lisa y Apple II.

En ese momento, los primeros sistemas de LAN recién salían al mercado, incluidos Ethernet, Token Ring, Econet y ARCNET. Este fue un tema de gran esfuerzo comercial en ese momento, dominando espectáculos como la Conferencia Nacional de Computación (NCC) en Anaheim en mayo de 1983. Todos los sistemas estaban compitiendo por una posición en el mercado, pero incluso en ese momento Ethernet's la aceptación generalizada sugirió que se convertiría en un estándar de facto. Fue en este programa que Steve Jobs le hizo a Gursharan Sidhu una pregunta aparentemente inocua: "¿Por qué las redes no se han puesto de moda?"

Cuatro meses después, en octubre, se canceló AppleNet. En ese momento, anunciaron que "Apple se dio cuenta de que no está en el negocio crear un sistema de red. Construimos y usamos AppleNet internamente, pero nos dimos cuenta de que si lo hubiéramos enviado, habríamos visto surgir nuevos estándares." En enero, Jobs anunció que, en cambio, apoyarían el Token Ring de IBM, que esperaba que saliera en 'unos pocos meses'.

AppleBus

A lo largo de este período, Apple estaba inmerso en el desarrollo de la computadora Macintosh. Durante el desarrollo, los ingenieros tomaron la decisión de utilizar el chip controlador serie (SCC) Zilog 8530 en lugar del UART más común y de menor costo para proporcionar conexiones de puerto serie. El SCC costaba alrededor de $5 más que un UART, pero ofrecía velocidades mucho más altas de hasta 250 kilobits por segundo (o más con hardware adicional) y admitía internamente una serie de protocolos básicos de red como Bisync de IBM.

Se eligió el SCC porque permitiría conectar múltiples dispositivos al puerto. Los periféricos equipados con SCC similares podrían comunicarse utilizando los protocolos integrados, intercalando sus datos con otros periféricos en el mismo bus. Esto eliminaría la necesidad de más puertos en la parte posterior de la máquina y permitiría la eliminación de las ranuras de expansión para admitir dispositivos más complejos. El concepto inicial se conocía como AppleBus y preveía un sistema controlado por el host Macintosh que sondeaba "tonto" dispositivos de una manera similar al moderno Universal Serial Bus.

Redes AppleBus

El equipo de Macintosh ya había comenzado a trabajar en lo que se convertiría en LaserWriter y había considerado otras opciones para responder a la pregunta de cómo compartir estas costosas máquinas y otros recursos. Una serie de memorandos de Bob Belleville aclararon estos conceptos, describiendo la Mac, LaserWriter y un sistema de servidor de archivos que se convertiría en Macintosh Office. A fines de 1983, estaba claro que el Token Ring de IBM no estaría listo a tiempo para el lanzamiento de la Mac y podría perderse el lanzamiento de estos otros productos también. Al final, Token Ring no se distribuiría hasta octubre de 1985.

Empleos' La pregunta anterior a Sidhu ya había provocado una serie de ideas. Cuando se canceló AppleNet en octubre, Sidhu lideró un esfuerzo para desarrollar un nuevo sistema de red basado en el hardware AppleBus. Este nuevo sistema no tendría que ajustarse a ninguna idea preconcebida existente y fue diseñado para ser digno de la Mac: un sistema que el usuario puede instalar, sin configuración y sin direcciones de red fijas; en resumen, un verdadero plug-and -jugar a la red. Se necesitó un esfuerzo considerable, pero cuando se lanzó la Mac, se habían esbozado los conceptos básicos y algunos de los protocolos de bajo nivel estaban en camino de completarse. Sidhu mencionó el trabajo a Belleville solo dos horas después de que se anunciara la Mac.

El "nuevo" AppleBus se anunció a principios de 1984, lo que permitía la conexión directa desde Mac o Lisa a través de una pequeña caja que se enchufaba en el puerto serie y se conectaba mediante cables a la siguiente computadora ascendente y descendente. También se anunciaron adaptadores para Apple II y Apple III. Apple también anunció que las redes AppleBus podrían conectarse a un sistema Token Ring y parecerían ser un solo nodo dentro de él. Los detalles de cómo funcionaría esto eran incompletos.

Red personal AppleTalk

Justo antes de su lanzamiento a principios de 1985, AppleBus pasó a llamarse AppleTalk. Comercializado inicialmente como AppleTalk Personal Network, comprendía una familia de protocolos de red y una capa física.

La capa física tenía una serie de limitaciones, incluida una velocidad de solo 230,4 kbit/s, una distancia máxima de 1000 pies (300 m) de extremo a extremo y solo 32 nodos por LAN. Pero como el hardware básico estaba integrado en la Mac, agregar nodos solo cuesta alrededor de $ 50 por la caja del adaptador. En comparación, las tarjetas Ethernet o Token Ring cuestan cientos o miles de dólares. Además, toda la pila de red requería solo alrededor de 6 kB de RAM, lo que le permitía ejecutarse en cualquier Mac.

La velocidad relativamente lenta de AppleTalk permitió mayores reducciones en el costo. En lugar de utilizar los circuitos balanceados de transmisión y recepción RS-422, el cableado AppleTalk usaba una sola tierra eléctrica común, que limitaba las velocidades a aproximadamente 500 kbit/s, pero permitía quitar un conductor. Esto significaba que se podían usar cables comunes de tres conductores para el cableado. Además, los adaptadores se diseñaron para ser "autoterminados", lo que significa que los nodos al final de la red podrían simplemente dejar su último conector desconectado. No había necesidad de volver a conectar los cables en un bucle, ni de concentradores u otros dispositivos.

El sistema fue diseñado para futuras expansiones; el sistema de direccionamiento permitía la expansión a 255 nodos en una LAN (aunque solo se podían usar 32 en ese momento), y mediante el uso de "puentes" (que llegó a conocerse como "enrutadores", aunque técnicamente no es lo mismo) uno podría interconectar LAN en colecciones más grandes. "Zonas" Permitió que los dispositivos fueran direccionados dentro de un Internet conectado por puente. Además, AppleTalk se diseñó desde el principio para permitir su uso con cualquier enlace físico subyacente potencial y, en unos pocos años, la capa física pasaría a llamarse LocalTalk, para diferenciarla de los protocolos de AppleTalk.

La principal ventaja de AppleTalk era que no necesitaba mantenimiento. Para unir un dispositivo a una red, un usuario simplemente enchufaba el adaptador en la máquina, luego conectaba un cable desde este a cualquier puerto libre en cualquier otro adaptador. La pila de red AppleTalk negoció una dirección de red, asignó a la computadora un nombre legible por humanos y compiló una lista de los nombres y tipos de otras máquinas en la red para que el usuario pudiera explorar los dispositivos a través del Selector. AppleTalk era tan fácil de usar que las redes ad hoc tendían a aparecer cada vez que había varias Mac en la misma habitación. Apple luego usaría esto en un anuncio que muestra la creación de una red entre dos asientos en un avión.

PhoneNet y otros adaptadores

En los próximos años se desarrolló un próspero mercado de terceros para dispositivos AppleTalk. Un ejemplo particularmente notable fue un adaptador alternativo diseñado por BMUG y comercializado por Farallon como PhoneNet en 1987. Este fue esencialmente un reemplazo para el conector de Apple que tenía conectores telefónicos convencionales en lugar de los conectores redondos de Apple. PhoneNet permitió que las redes AppleTalk se conectaran entre sí mediante cables telefónicos normales y, con muy poco trabajo adicional, podía ejecutar teléfonos analógicos y AppleTalk en un solo cable telefónico de cuatro conductores.

Otras empresas aprovecharon la capacidad del SCC de leer relojes externos para admitir velocidades de transmisión más altas, de hasta 1 Mbit/s. En estos sistemas, el adaptador externo también incluía su propio reloj y lo usaba para señalar los pines de entrada del reloj del SCC. El sistema de este tipo más conocido era el FlashTalk de Centram, que funcionaba a 768 kbit/s y estaba destinado a ser utilizado con su sistema de red TOPS. Una solución similar fue el DaynaTalk de 850 kbit/s, que usaba una caja separada que se conectaba entre la computadora y una caja normal de LocalTalk/PhoneNet. Dayna también ofreció una tarjeta de expansión para PC que funcionaba hasta 1,7 Mbit/s cuando se comunicaba con otras tarjetas para PC de Dayna. También existían varios otros sistemas con un rendimiento aún mayor, pero estos a menudo requerían un cableado especial que era incompatible con LocalTalk/PhoneNet, y también requerían parches para la pila de redes que a menudo causaban problemas.

AppleTalk a través de Ethernet

A medida que Apple se expandía hacia mercados más comerciales y educativos, necesitaban integrar AppleTalk en las instalaciones de red existentes. Muchas de estas organizaciones ya habían invertido en una infraestructura Ethernet muy costosa y no había forma directa de conectar una Macintosh a Ethernet. AppleTalk incluía una estructura de protocolo para interconectar subredes de AppleTalk y, como solución, EtherTalk se creó inicialmente para utilizar Ethernet como columna vertebral entre las subredes de LocalTalk. Para lograr esto, las organizaciones necesitarían comprar un puente LocalTalk-to-Ethernet y Apple dejó que terceros fabricaran estos productos. Varias empresas respondieron, incluidas Hayes y algunas empresas recién formadas como Kinetics.

LocalTalk, EtherTalk, TokenTalk y AppleShare

En 1987, Ethernet claramente estaba ganando la batalla de los estándares sobre Token Ring y, a mediados de ese año, Apple presentó EtherTalk 1.0, una implementación del protocolo AppleTalk sobre la capa física de Ethernet. Presentado para la computadora Macintosh II recientemente lanzada, la primera Macintosh de Apple con ranuras de expansión, el sistema operativo incluía un nuevo panel de control de red que permitía al usuario seleccionar qué conexión física usar para la red (desde "Built- en" o "EtherTalk"). En la introducción, las tarjetas de interfaz Ethernet estaban disponibles en 3Com y Kinetics que se conectaban a una ranura Nubus en la máquina. La nueva pila de redes también amplió el sistema para permitir 255 nodos completos por LAN. Con el lanzamiento de EtherTalk, AppleTalk Personal Network pasó a llamarse LocalTalk, el nombre con el que se conocería durante la mayor parte de su vida. Más tarde, Token Ring sería compatible con el producto TokenTalk similar, que utilizaba el mismo panel de control de red y el mismo software subyacente. Con el tiempo, muchas empresas de terceros introducirían tarjetas Ethernet y Token Ring compatibles que usaban estos mismos controladores.

La aparición de un Macintosh con una conexión Ethernet directa también magnificó el problema de compatibilidad de Ethernet y LocalTalk: las redes con Mac nuevos y antiguos necesitaban alguna forma de comunicarse entre sí. Esto podría ser tan simple como una red de Ethernet Mac II tratando de comunicarse con un LaserWriter que solo se conecta a LocalTalk. Apple inicialmente se basó en los productos de puente LocalTalk-to-Ethernet antes mencionados, pero contrariamente a la creencia de Apple de que estos serían productos de bajo volumen, a fines de 1987, 130,000 de esas redes estaban en uso. AppleTalk era en ese momento el sistema de red más utilizado del mundo, con más del triple de instalaciones que cualquier otro proveedor.

1987 también marcó la introducción del producto AppleShare, un servidor de archivos dedicado que se ejecutaba en cualquier Mac con 512 kB de RAM o más. Una máquina AppleShare común era la Mac Plus con un disco duro SCSI externo. AppleShare fue el tercer sistema operativo de red a fines de la década de 1980, detrás de Novell NetWare y MS-Net de Microsoft. AppleShare fue efectivamente el reemplazo de los esfuerzos fallidos de Macintosh Office, que se habían basado en un dispositivo de servidor de archivos dedicado.

AppleTalk Fase II y otras novedades

En 1989 se lanzó un importante rediseño como AppleTalk Phase II. En muchos sentidos, la Fase II puede considerarse un esfuerzo por hacer que la versión anterior (nunca llamada Fase I) sea más genérica. Las LAN ahora podían admitir más de 255 nodos, y las zonas ya no estaban asociadas con redes físicas, sino que eran construcciones completamente virtuales que se usaban simplemente para organizar los nodos. Por ejemplo, ahora se podría hacer un "Impresoras" zona que enumeraría todas las impresoras en una organización, o uno podría querer colocar ese mismo dispositivo en el "segundo piso" zona para indicar su ubicación física. La Fase II también incluyó cambios en los protocolos de interconexión de redes subyacentes para hacerlos menos 'habladores', lo que anteriormente había sido un problema grave en las redes que se conectaban a través de redes de área amplia.

En ese momento, Apple tenía una amplia variedad de productos de comunicación en desarrollo, y muchos de ellos se anunciaron junto con AppleTalk Phase II. Estos incluyeron actualizaciones de EtherTalk y TokenTalk, software AppleTalk y hardware LocalTalk para IBM PC, EtherTalk para el sistema operativo A/UX de Apple que le permite usar impresoras láser y otros recursos de red, y los productos Mac X.25 y MacX.

Ethernet se había vuelto casi universal en 1990, y era hora de integrar Ethernet en las Mac directamente desde la fábrica. Sin embargo, el cableado físico utilizado por estas redes aún no estaba completamente estandarizado. Apple resolvió este problema utilizando un solo puerto en la parte posterior de la computadora en el que el usuario podía conectar un adaptador para cualquier sistema de cableado dado. Este sistema FriendlyNet se basó en la interfaz de unidad de conexión estándar de la industria o AUI, pero eligió deliberadamente un conector no estándar que era más pequeño y más fácil de usar, al que llamaron "Apple AUI", o AAUI. FriendlyNet se introdujo por primera vez en las computadoras Quadra 700 y Quadra 900, y se usó en gran parte de la línea Mac durante algún tiempo. Al igual que con LocalTalk, rápidamente aparecieron una serie de adaptadores FriendlyNet de terceros.

Cuando 10BASE-T se convirtió en el sistema de cableado de facto para Ethernet, las máquinas Power Macintosh de segunda generación agregaron un puerto 10BASE-T además de AAUI. El PowerBook 3400c y los Power Mac de gama baja también agregaron 10BASE-T. Los Power Macintosh 7300/8600/9600 fueron los últimos Mac en incluir AAUI, y 10BASE-T se volvió universal a partir del Power Macintosh G3 y el PowerBook G3.

La capital-I Internet

Desde el comienzo de AppleTalk, los usuarios querían conectar el Macintosh a los entornos de red TCP/IP. En 1984, Bill Croft de la Universidad de Stanford fue pionero en el desarrollo de paquetes IP encapsulados en DDP como parte del proyecto SEAGATE (Stanford Ethernet - AppleTalk Gateway). SEAGATE fue comercializado por Kinetics en su puente LocalTalk-to-Ethernet como una opción de enrutamiento adicional. Unos años más tarde, MacIP se separó del código SEAGATE y se convirtió en el método de facto para enrutar paquetes IP a través de redes LocalTalk. En 1986, la Universidad de Columbia lanzó la primera versión del Paquete Columbia AppleTalk (CAP) que permitía una mayor integración de los entornos Unix, TCP/IP y AppleTalk. En 1988, Apple lanzó MacTCP, un sistema que permitía que la Mac fuera compatible con TCP/IP en máquinas con hardware Ethernet adecuado. Sin embargo, esto dejó a muchas universidades con el problema de admitir IP en sus muchos Mac equipados con LocalTalk. Pronto fue común incluir compatibilidad con MacIP en los puentes LocalTalk-to-Ethernet. MacTCP no se convertiría en una parte estándar del Classic Mac OS hasta 1994, momento en el que también admitía SNMP y PPP.

Durante algún tiempo a principios de la década de 1990, la Mac fue un cliente principal en la Internet en rápida expansión. Entre los programas más conocidos y de amplio uso estaban Fetch, Eudora, eXodus, NewsWatcher y los paquetes NCSA, especialmente NCSA Mosaic y su descendiente, Netscape Navigator. Además, aparecieron una serie de productos de servidor que permitían a la Mac alojar contenido de Internet. A lo largo de este período, las Mac tenían de 2 a 3 veces más clientes conectados a Internet que cualquier otra plataforma, a pesar de la participación de mercado general relativamente pequeña de las microcomputadoras.

A medida que el mundo pasó rápidamente a IP para usos de LAN y WAN, Apple se enfrentó a mantener dos bases de código cada vez más obsoletas en un grupo cada vez más amplio de máquinas, así como a la introducción de máquinas basadas en PowerPC. Esto condujo a los esfuerzos de Open Transport, que volvieron a implementar tanto MacTCP como AppleTalk en una base de código completamente nueva adaptada del estándar Unix STREAMS. Las primeras versiones tenían problemas y no se estabilizaron durante algún tiempo. En ese momento, Apple estaba inmerso en sus esfuerzos Copland finalmente condenados.

Legado y abandono

Con la compra de NeXT y el posterior desarrollo de Mac OS X, AppleTalk era estrictamente un sistema heredado. Se agregó soporte a OS X para brindar soporte para la gran cantidad de dispositivos AppleTalk existentes, en particular impresoras láser y archivos compartidos, pero las soluciones de conexión alternativas comunes en esta era, en particular USB para impresoras, limitaron su demanda. Como Apple abandonó muchas de estas categorías de productos y todos los nuevos sistemas se basaron en IP, AppleTalk se volvió cada vez menos común. La compatibilidad con AppleTalk finalmente se eliminó de MacOS en Mac OS X v10.6 en 2009.

Sin embargo, la pérdida de AppleTalk no redujo el deseo de soluciones de red que combinaran su facilidad de uso con el enrutamiento IP. Apple ha liderado el desarrollo de muchos de estos esfuerzos, desde la introducción del enrutador AirPort hasta el desarrollo del sistema de red de configuración cero y su implementación, Bonjour.

A partir de 2020, la compatibilidad con AppleTalk se eliminó por completo de la compatibilidad heredada con macOS 11 Big Sur.

Diseño

El diseño de AppleTalk siguió rigurosamente el modelo OSI de capas de protocolo. A diferencia de la mayoría de los primeros sistemas LAN, AppleTalk no se creó utilizando el sistema arquetípico Xerox XNS. El objetivo previsto no era Ethernet y no tenía direcciones de 48 bits para enrutar. Sin embargo, muchas partes del sistema AppleTalk tienen análogos directos en XNS.

Una diferenciación clave de AppleTalk era que contenía dos protocolos destinados a hacer que el sistema se autoconfigurara por completo. El protocolo de resolución de direcciones de AppleTalk (AARP) permitía a los hosts de AppleTalk generar automáticamente sus propias direcciones de red, y el protocolo de vinculación de nombres (NBP ) era un sistema dinámico para asignar direcciones de red a nombres legibles por el usuario. Aunque sistemas similares a AARP existían en otros sistemas, Banyan VINES por ejemplo. A partir de 2002, el DNS de multidifusión proporcionó capacidades similares a NBP.

Tanto AARP como NBP habían definido formas de permitir que el "controlador" dispositivos para anular los mecanismos predeterminados. El concepto era permitir que los enrutadores proporcionaran la información o el "cableado" el sistema a direcciones y nombres conocidos. En redes más grandes donde AARP podría causar problemas a medida que los nuevos nodos buscaran direcciones libres, la adición de un enrutador podría reducir la "conversación". Juntos, AARP y NBP hicieron de AppleTalk un sistema de red fácil de usar. Se agregaron nuevas máquinas a la red enchufándolas y, opcionalmente, dándoles un nombre. Las listas de NBP fueron examinadas y mostradas por un programa conocido como Chooser que mostraría una lista de máquinas en la red local, dividida en clases como servidores de archivos e impresoras.

Direccionamiento

Una dirección AppleTalk era una cantidad de cuatro bytes. Este consistía en un número de red de dos bytes, un número de nodo de un byte y un número de socket de un byte. De estos, solo el número de red requería alguna configuración, ya que se obtenía de un enrutador. Cada nodo eligió dinámicamente su propio número de nodo, de acuerdo con un protocolo (originalmente, el Protocolo de acceso a enlaces de LocalTalk LLAP y más tarde, para Ethernet/EtherTalk, el Protocolo de resolución de direcciones de AppleTalk, AARP) que manejó la contención entre diferentes nodos que eligieron accidentalmente el mismo número. Para los números de socket, se reservaron algunos números conocidos para fines especiales específicos del protocolo AppleTalk en sí. Además de estos, se esperaba que todos los protocolos de nivel de aplicación usaran números de socket asignados dinámicamente tanto en el extremo del cliente como en el del servidor.

Debido a este dinamismo, no se podía esperar que los usuarios accedieran a los servicios especificando su dirección. En cambio, todos los servicios tenían nombres que, al ser elegidos por humanos, se podía esperar que fueran significativos para los usuarios, y también podían ser lo suficientemente largos como para minimizar la posibilidad de conflictos.

Como los nombres de NBP se traducían a una dirección, que incluía un número de socket y un número de nodo, un nombre en AppleTalk se asignaba directamente a un servicio proporcionado por una máquina, que estaba completamente separada de el nombre de la máquina en sí. Por lo tanto, los servicios se podían mover a una máquina diferente y, siempre que mantuvieran el mismo nombre de servicio, no era necesario que los usuarios hicieran nada diferente para continuar accediendo al servicio. Y la misma máquina podría albergar cualquier cantidad de instancias de servicios del mismo tipo, sin ningún conflicto de conexión de red.

Compare esto con los registros A en el DNS, en los que un nombre se traduce en la dirección de una máquina, sin incluir el número de puerto que podría estar proporcionando un servicio. Por lo tanto, si las personas están acostumbradas a usar un nombre de máquina en particular para acceder a un servicio en particular, su acceso se interrumpirá cuando el servicio se mueva a una máquina diferente. Esto se puede mitigar un poco al insistir en usar registros CNAME que indiquen el servicio en lugar de los nombres reales de las máquinas para hacer referencia al servicio, pero no hay forma de garantizar que los usuarios sigan tal convención. Algunos protocolos más nuevos, como Kerberos y Active Directory, utilizan registros DNS SRV para identificar los servicios por nombre, lo que se acerca mucho más al modelo AppleTalk.

Protocolos

Protocolo de resolución de direcciones de AppleTalk

AARP resuelve las direcciones de AppleTalk en direcciones de capa de enlace, normalmente direcciones MAC. Es funcionalmente equivalente a ARP y obtiene la resolución de direcciones por un método muy similar a ARP.

AARP es un sistema bastante simple. Cuando se enciende, una máquina AppleTalk transmite un paquete de sonda AARP solicitando una dirección de red, con la intención de recibir respuesta de los controladores, como los enrutadores. Si no se proporciona ninguna dirección, se elige una al azar de la 'subred base', 0. Luego transmite otro paquete que dice 'Estoy seleccionando esta dirección', y luego espera para ver si cualquier otra persona en la red se queja. Si otra máquina tiene esa dirección, elegirá otra dirección y seguirá intentándolo hasta que encuentre una libre. En una red con muchas máquinas, pueden ser necesarios varios intentos antes de encontrar una dirección libre, por lo que, por motivos de rendimiento, la dirección correcta se "anota" en NVRAM y se utilizará como dirección predeterminada en el futuro. Esto significa que en la mayoría de las configuraciones del mundo real donde las máquinas se agregan unas pocas a la vez, solo se necesitan uno o dos intentos antes de que la dirección se vuelva constante.

Protocolo de flujo de datos de AppleTalk

Esta fue una adición relativamente tardía al conjunto de protocolos AppleTalk, realizada cuando se hizo evidente que se necesitaba un transporte confiable orientado a la conexión al estilo TCP. Las diferencias significativas con TCP fueron que:

• a connection attempt could be rejected
• no había conexiones "half-open"; una vez que un extremo inició una ruptura de la conexión, toda la conexión estaría cerrada (i.e., ADSP es un dúplex completo, no dual simplex).
• AppleTalk tenía un sistema de mensajes de atención incluido que permitía enviar mensajes cortos que evitarían el flujo normal de datos de flujo. Estos fueron entregados de forma fiable pero fuera de orden con respecto a la corriente. Cualquier mensaje de atención sería entregado tan pronto como sea posible en lugar de esperar que el punto de secuencia actual de byte se vuelva actual.

Protocolo de archivo de Apple

El Protocolo de archivo de Apple (AFP), anteriormente llamado Protocolo de archivo de AppleTalk, es el protocolo para comunicarse con los servidores de archivos de AppleShare. Construido sobre el Protocolo de sesión de AppleTalk (para AFP heredado sobre DDP) o la Interfaz de flujo de datos (para AFP sobre TCP), proporciona servicios para autenticar a los usuarios (extensible a diferentes métodos de autenticación, incluido el intercambio de números aleatorios bidireccionales) y para realizar operaciones específicas del sistema de archivos HFS de Macintosh. AFP todavía está en uso en macOS, aunque la mayoría de los otros protocolos de AppleTalk han quedado obsoletos.

Protocolo de sesión de AppleTalk

ASP era un protocolo intermedio, creado sobre ATP, que a su vez era la base de AFP. Proporcionó servicios básicos para solicitar respuestas a comandos arbitrarios y realizar consultas de estado fuera de banda. También permitía que el servidor enviara mensajes de atención asincrónicos al cliente.

Protocolo de entrega de datagramas

DDP era el protocolo de transporte independiente del enlace de datos de nivel más bajo. Proporcionó un servicio de datagramas sin garantías de entrega. Todos los protocolos de nivel de aplicación, incluidos los protocolos de infraestructura NBP, RTMP y ZIP, se crearon sobre DDP. El DDP de AppleTalk se corresponde estrechamente con la capa de red del modelo de comunicación de interconexión de sistemas abiertos (OSI).

Protocolo de vinculación de nombres

El protocolo de vinculación de nombres era un sistema dinámico y distribuido para administrar nombres de AppleTalk. Cuando un servicio se iniciaba en una máquina, registraba un nombre para sí mismo elegido por un administrador humano. En este punto, NBP proporcionó un sistema para comprobar que ninguna otra máquina ya había registrado el mismo nombre. Más tarde, cuando un cliente quería acceder a ese servicio, usaba NBP para consultar máquinas para encontrar ese servicio. NBP brindó navegabilidad ("¿cuáles son los nombres de todos los servicios disponibles?"), así como también la capacidad de encontrar un servicio con un nombre particular. Los nombres eran legibles por humanos, contenían espacios, letras mayúsculas y minúsculas e incluían soporte para búsqueda.

Protocolo de eco AppleTalk

AEP (AppleTalk Echo Protocol) es un protocolo de capa de transporte diseñado para probar la accesibilidad de los nodos de la red. AEP genera paquetes para enviar al nodo de red y se identifica en el campo Tipo de un paquete como un paquete AEP. El paquete se pasa primero al DDP de origen. Una vez que se identifica como un paquete AEP, se reenvía al nodo donde el DDP examina el paquete en el destino. Una vez que el paquete se identifica como un paquete AEP, el paquete se copia y un campo del paquete se modifica para crear un paquete de respuesta AEP, y luego se devuelve al nodo de origen.

Protocolo de acceso a la impresora

PAP era la forma estándar de comunicarse con las impresoras PostScript. Fue construido sobre ATP. Cuando se abría una conexión PAP, cada extremo enviaba al otro una solicitud ATP que básicamente significaba "envíame más datos". La respuesta del cliente al servidor fue enviar un bloque de código PostScript, mientras que el servidor podía responder con cualquier mensaje de diagnóstico que pudiera generarse como resultado, después de lo cual otro "enviar más datos" se envió la solicitud. Este uso de ATP proporcionó un control de flujo automático; cada extremo solo podía enviar datos al otro extremo si había una solicitud ATP pendiente a la que responder.

PAP también proporcionó consultas de estado fuera de banda, manejadas por transacciones ATP separadas. Incluso mientras estaba ocupado dando servicio a un trabajo de impresión de un cliente, un servidor PAP podía seguir respondiendo a las solicitudes de estado de cualquier número de otros clientes. Esto permitió que otros Macintosh en la LAN que estaban esperando para imprimir mostraran mensajes de estado que indicaban que la impresora estaba ocupada y con qué trabajo estaba ocupada.

Protocolo de mantenimiento de tablas de enrutamiento

RTMP era el protocolo mediante el cual los enrutadores se mantenían informados entre sí sobre la topología de la red. Esta era la única parte de AppleTalk que requería transmisiones periódicas no solicitadas: cada 10 segundos, cada enrutador tenía que enviar una lista de todos los números de red que conocía y cuán lejos creía que estaban.

Protocolo de información de zona

ZIP era el protocolo mediante el cual los números de red de AppleTalk se asociaban con los nombres de las zonas. Una zona era una subdivisión de la red que tenía sentido para los humanos (por ejemplo, "Departamento de Contabilidad"); pero mientras que un número de red tenía que ser asignado a una sección topológicamente contigua de la red, una zona podía incluir varias porciones diferentes no contiguas de la red.

Implementación física

Interior de Apple Local Interfaz de conversación. En 1989, estas cajas suelen costar 90 dólares cada una. Los conectores cuentan con la terminación eléctrica automática del autobús señal LocalTalk; la inserción de un cable de autobús LocalTalk deprime un interruptor normalmente cerrado detrás del conector, desactivando la terminación para ese conector.

Farallon PhoneNET adaptador

La implementación de hardware predeterminada inicial para AppleTalk era un protocolo serie de alta velocidad conocido como LocalTalk que utilizaba los puertos RS-422 integrados de Macintosh a 230,4 kbit/s. LocalTalk usó una caja divisora en el puerto RS-422 para proporcionar un cable ascendente y descendente desde un solo puerto. La topología era un bus: los cables estaban conectados en cadena desde cada máquina conectada a la siguiente, hasta el máximo de 32 permitido en cualquier segmento de LocalTalk. El sistema era lento para los estándares actuales, pero en ese momento el costo adicional y la complejidad de las redes en las máquinas PC eran tales que era común que las Mac fueran las únicas computadoras personales conectadas en red en una oficina. Otras computadoras más grandes, como las estaciones de trabajo UNIX o VAX, normalmente se conectarían en red a través de Ethernet.

También estaban disponibles otras implementaciones físicas. Un reemplazo muy popular para LocalTalk fue PhoneNet, una solución de terceros de Farallon Computing, Inc. (rebautizada como Netopia, adquirida por Motorola en 2007) que también usaba el puerto RS-422 y no se distinguía de LocalTalk como en lo que respecta a los controladores de puerto LocalTalk de Apple, pero pasó por encima de los dos hilos no utilizados en el cableado telefónico estándar de cuatro hilos. Como presagio de los concentradores y conmutadores de red actuales, Farallon proporcionó soluciones para que PhoneNet se usara en "star" así como configuraciones de bus, tanto con "pasivo" conexiones en estrella (con los cables telefónicos simplemente conectados entre sí en un punto central) y "activo" estrella con "PhoneNet Star Controller" hardware del concentrador. Los conectores LocalTalk de Apple no tenían una función de bloqueo, por lo que los conectores podían soltarse fácilmente, y la configuración del bus provocaba que cualquier conector suelto colapsara toda la red y fuera difícil de rastrear. Los conectores PhoneNet RJ-11, por otro lado, encajaron en su lugar, y en una configuración en estrella, cualquier problema de cableado solo afectaba a un dispositivo, y los problemas eran fáciles de identificar. El bajo costo, la flexibilidad y la fácil solución de problemas de PhoneNet dieron como resultado que fuera la opción dominante para las redes Mac a principios de la década de 1990.

Los protocolos AppleTalk también llegaron a ejecutarse sobre Ethernet (primero coaxial y luego par trenzado) y capas físicas Token Ring, etiquetadas por Apple como EtherTalk y TokenTalk, respectivamente. EtherTalk se convirtió gradualmente en el método de implementación dominante para AppleTalk a medida que Ethernet se hizo popular en la industria de las PC durante la década de 1990. Además de AppleTalk y TCP/IP, cualquier red Ethernet también podría transportar simultáneamente otros protocolos como DECnet e IPX.

Modelo de red

Versiones

Soluciones multiplataforma

Cuando se introdujo por primera vez AppleTalk, la plataforma informática de oficina predominante era la PC compatible con MS-DOS. Apple presentó la tarjeta para PC AppleTalk a principios de 1987, lo que permitía que las PC se unieran a redes AppleTalk e imprimieran en impresoras LaserWriter. Un año después, se lanzó AppleShare PC, que permite a las PC acceder a los servidores de archivos de AppleShare.

El "TOPS Teleconector" El sistema de red MS-DOS sobre el sistema AppleTalk permitió que las PC MS-DOS se comunicaran a través del hardware de red AppleTalk; comprendía una tarjeta de interfaz AppleTalk para la PC y un conjunto de software de red que permitía funciones tales como compartir archivos, unidades e impresoras. Además de permitir la construcción de una red AppleTalk solo para PC, permitió la comunicación entre PC y Mac con el software TOPS instalado. (Las Mac sin TOPS instalado podrían usar la misma red, pero solo para comunicarse con otras máquinas Apple). el software DOS era relativamente simple de usar en términos de DOS y era robusto.

Los sistemas operativos BSD y Linux admiten AppleTalk a través de un proyecto de código abierto llamado Netatalk, que implementa el conjunto completo de protocolos y les permite actuar como servidores nativos de archivo o impresión para computadoras Macintosh e imprimir en impresoras LocalTalk a través de la red.

Los sistemas operativos Windows Server eran compatibles con AppleTalk desde Windows NT hasta Windows Server 2003. Miramar incluyó AppleTalk en su producto PC MacLAN, que CA descontinuó en 2007. GroupLogic continúa empaquetando su protocolo AppleTalk con su servidor ExtremeZ-IP. software para la integración Macintosh-Windows que admite Windows Server 2008 y Windows Vista, así como versiones anteriores. HELIOS Software GmbH ofrece una implementación propietaria de la pila de protocolos AppleTalk, como parte de su servidor HELIOS UB2. Se trata esencialmente de un conjunto de servidores de archivos e impresión que se ejecuta en una amplia gama de plataformas diferentes.

Además, la Universidad de Columbia lanzó el paquete AppleTalk de Columbia (CAP) que implementó el conjunto de protocolos para varias variantes de Unix, incluidas Ultrix, SunOS, *BSD e IRIX. Este paquete ya no se mantiene activamente.